Great.
So, there are three safe ways to deal with this problem.
-
One deletes “object_of_MyClass” AFTER the tree is deleted … one of …
1.a delete My_Tree; delete object_of_MyClass; delete pointer_to_file;
1.b delete My_Tree; delete pointer_to_file; delete object_of_MyClass;
1.c delete pointer_to_file; delete object_of_MyClass; -
One deletes “object_of_MyClass” BEFORE the tree is deleted (note: setting “object_of_MyClass = 0;”, BEFORE the tree is going to be deleted, either explicitly or implicitly, is MANDATORY) … one of …
2.a delete object_of_MyClass; object_of_MyClass = 0; delete My_Tree; delete pointer_to_file;
2.b delete object_of_MyClass; object_of_MyClass = 0; delete pointer_to_file; -
One first calls “bntrack1->SetAddress(0);” or “My_Tree->ResetBranchAddress(bntrack1);” or “My_Tree->ResetBranchAddresses();” and then the “object_of_MyClass” is no longer “associated” with the tree in any way, so one can delete it in any moment (either before or after “delete My_Tree;” and/or “delete pointer_to_file;”, and there is no need to set “object_of_MyClass = 0;”):
http://root.cern.ch/root/html/TTree.html#TTree:ResetBranchAddress
http://root.cern.ch/root/html/TTree.html#TTree:ResetBranchAddresses
(Well, the descriptions of both of the above methods seem to be a bit short and there’s just that slightly worrying “Note: If any of our branches own any objects, they are deleted.”)
Note that, in any case, the “delete pointer_to_file;” call will automatically delete “My_Tree”, if it was not deleted in advance (so the “delete My_Tree;” call is usually redundant).
BTW. Maybe someone could add some notes about the ownership of objects in the “TTree” class description , in “==> Case B” at least, and in the “TTree::GetEntry” description.