Behaviour of TRef

Dear ROOT experts,

in the context of an HistFactory bug report, we realised a suspicious behaviour of the TRef class. We would like to know whether this behaviour is expected (and if so, why)? I also attached a short macro illustrating the question.

Suppose one initialises a TRef object with a (new) histogram pointer, then the TRef object obviously points to this very same histogram. If one then creates a clone of the histogram, the TRef points to this clone rather to the original histogram. (I personally find this behviour quite dangerous.) Moreover, if one creates another clone of the first clone, the TRef still points to the first cloned object. So it is not a generic behaviour that a TRef will always point to the last cloned object.
But there is something I find even more confusing. The TRef is still pointing at the first clone. As an user I would expect that there is no other link or dependency of the TRef object to any other object (except the object it is pointing to, of course). If one now clones the original histogram again, the TRef object suddenly points to this new (third) clone, why?

I am very puzzled by this behaviours as it seems to me that there are more hidden links between objects and TRef’s than the obvious one.

Thanks for your help
Christian

RefClone.cxx (998 Bytes)

Hi.

I had a look at how TRef works (I have never worked with this class before). It uses object’s UUID to keep a “reference” to the original object. Your first ‘h’ does not have an UUID so TRef assigns it (it’s 1).
After ‘Clone’ called, you have several hists all with the same UUID == 1. What happens and how - you can have a look at TDirectoryFile::CloneObject and investigate, why sometimes the object with UUID 1 is the same as before the Clone, sometimes it’s not - but it’s not interesting actually.

So, either call all ‘Clone’ before creating a reference, or … do not call ‘Clone’ and create a copy in a different way?

Otherwise, I think you are misusing TRef (though documentation should definitely mention this problem).

Hi,

I had a quick look on how TRef works and I understood the principle you are outlining. It might be that TRef have been used in a situation it hasn’t been designed for.
However, I feel that the behaviour of breaking the link between a TRef and an object A by modifying an object B somewhere else in the code is dangerous, especially if it is not mentioned anywhere. As an user I expect a TRef object to work like the name suggests.

Cheers
Christian

[quote=“cgumpert”]Hi,

I had a quick look on how TRef works and I understood the principle you are outlining. It might be that TRef have been used in a situation it hasn’t been designed for.
However, I feel that the behaviour of breaking the link between a TRef and an object A by modifying an object B somewhere else in the code is dangerous, especially if it is not mentioned anywhere. As an user I expect a TRef object to work like the name suggests.

Cheers
Christian[/quote]

The link is not broken, TRef still references the object with a given UUID, this UUID is the object’s identity.
Clone operation also “clones” an UUID, an here you “break the link”.
May be, Clone should also generate a new UUID, but may be it must copy it due to some other reasons.

While the behaviour you’re observing may be not so obvious, it’s still quite logical. Though, of course, it must be documented. And I do not think that there are other operations creating an object with the same UUID.