For example in TList::Clear() there’s code like this:
Using the mindset of a C++ programmer, the code looks absurd: how one is supposed to read already destroyed object? Is there detailed documentation what the flag is actually for? [url=https://root-forum.cern.ch/t/who-owns-this-tobject/9691/3 hints[/url] I could find suggested that it is essentially an undefined behaviour hack.
Dear tc3t,
Unfortunately there is no detailed documentation, but the main useful purpose of this flag is related to TClonesArray. Objects have this bit set by default, so by default the condition you mention resolves to ‘true’.
Not sure if this helps.
G Ganis
Thanks for the answer. The question arised from debugging a crash which seemed to result from TList-methods touching already deleted objects. For example if one knows the address of a deleted pad primitive and wants to removed it from pad, it was surprising that TList::Remove(TObject*) for pad’s list of primitives will actually cause a crash, because it uses TList::FindLink() which will touch the object. Why it needs to touch is not directly related to the question since the need comes from use of TObject::IsEqual(), but since kNotDeleted was used in the same place, I got interested to know how the whole TList semantics is designed to work.
Hi,
On a somewhat side note, when a TObject is deleted, it should automatically be removed (by the TObject destructor via the list of cleanups) from a TPad.
Cheers,
Philippe.
The bad thing is that the automatic removal is not thread safe and thus may cause crashes if used (e.g. ROOT-7173).
Hi,
Indeed, this is a known problem … hard to solve with sacrificing performance. Nonetheless we are working on a solution.
Cheers,
Philippe.