I’ve got a question about what exactly happens with TRefs and their associated objects when they are written to and then read from file. I noticed that before writing a TClonesArray to file, the uid’s of the objects are different from those of the objects that I get back from file. However, the steps between uid’s of subsequent objects appear to be the same before and after the file. So I guess these uid’s are created on-the-fly when creating objects or reading objects from file. Now comes the question: if the uid’s are stored to file together with the objects, why not just use these? Who (re)assigns the uid’s and when?
Thanks for your help,
Jeroen
P.S. Is it a feature that creating a TRef to another TRef makes the reference to the original object (the one the first TRef pointed to) gets lost? In this case the two TRefs just point at eachother.
I found out that there seems to be a steady 16777216 difference between the uid of an object before writing it to file and after retreiving it. Since 16777216=2^24 and TProcessID seems to treat the lower 24 bits of a uid differently from the rest, the question is: what do the other bits mean?
Another thing I was wondering about is this: are these uid’s only used by TRefs? In other words, if an object’s uid != 0, does that mean theres’ a TRef pointing at it? And another one: there seems to be no roll-over protection in the AssignID() method (it looks like it will just keep increasing the object count and ignore the 24 bit restriction), though there are warnings in the documentation that you may have to reset the object count.
I’m not just messing around. Somehow, every once in a lot of event, I end up with two different objects having the same uid. This gives interesting results if you dereference a TRef pointing to one and you get the other, only cast to the wrong type.