OK, after consulting https://root.cern.ch/doc/master/classTRef.html I think it worth trying swapping the TRefArrays (one process ID supported) to std::vector<TRef*> s (multiple process IDs suported, one per TRef). Jan could you try this and let me know?

Update: swapping to std::vector<TRef*> is not so simple as there does not seem to be a TRefProcessor class written. Chris R, could you advise - do you away of using std::vector<TRef*> in the MAUS processor framework?

Is the problem arising during conversion from Json to C++? The TRefProcessor would only be called during conversion. I rather thought the issue was in serialisation/deserialisation of the ROOT tree and Json has nothing to do with it.

• make an area in the data tree which is like std::set<TObject*> references;
• invent a MAUSRef* (perhaps some stl object exists like std::auto_ptr)
• someone makes a MAUSRef* we dump the actual data in std::map<TObject*, size_t> (TRefProcessor does this I guess)
• Only one pointer to the MAUSRef* does a look up on the std::map during dereference operation, so ROOT only ever stores one instance of the target object (from the std::map).
• Reference counting could be implemented and then this becomes a full smart pointer set up.

Hope that makes some sense. Probably ROOT already does this for us, if we only knew how to get the TRef thing to work.

Hi Chris,

Thanks, yes, this is trying to create a processor for doing JSON / Cpp conversion. It is not necessary for what we want to do (ROOT I/O) however I assumed the MAUS framework requires it. Let me explain more fully:

• TRefArray is used by the Global data structure to provide cross-links (MAUS policy) to prevent data replication in the final ROOT file
• TRefArray have to contain objects created by the same process ID. When Jan or whoever runs MAUS several times and updates the data containers the TRefArray has a hissy fit due the different process IDs
• The ROOT way of dealing with this is to switch out the TRefArrays in favour of std::vector<TRef*>s (less efficient, but no problems with different PIDs as each TRef* has its own PID)

So far so good. Jan has changed his data structure to use std::vector<TRef*>, however when we tried to update the corresponding JsonCppProcessor in MAUS, by adding a PointerArrayProcessor<TRef*> member to the Global TrackProcessor, we found that there was no TRefProcessor to process TRefs. I have tried writing one but so far unsuccessfully (the existing code handles TRefs and TRefArrays quite different for some reason).

We could try not bothering with updating the JsonCppProcessor, as we don't use JSON anymore anyway, and see if the framework accepts that without too much trouble.

I am not sure I follow your idea about implementing a new type of smart pointer - we need to use TRef's in order to do serialisation/deserialisation for the ROOT file, unless you mean to make a smart pointer to do that instead of TRef (ugh...). C++11 already has nice smart pointers bundled (ref counting), but I don't see what it gains us.

Update: I tried running without entering the TRef entries into the Global TrackProcessor, got it to compile but it then seg faulted at run time. It seems MAUS running is still bound to JSONCppProcessors...