I’ve read the user guide sections on this multiple times, but remain confused. 2.6 begins by stating “ROOT has a set of global variables that apply to the session.” – does session mean interactive session, as distinguished from code that’s separately compiled and linked against ROOT? If so, are global variables treated differently in the latter case?
Evidently one can partially control what some ROOT global variables own, but I can’t reason about when and why this is true. For example, is it true that a user-created class can have a TH1 data member and not worry about double-deletion iff one calls
first? The global variable gDirectory will still own user-created trees and events though, correct? So presumably a user-defined class ought to have only member references/pointers to trees/events (and not instances of them)? And this is always true for TCanvases, which can never be owned by the user, right?
My hope is to find the simplest way possible to interact w/ ROOT using the standard C++ rules for object ownership. I don’t trust myself to deal with all the special cases, kCanDelete & kMustCleanup bits, &c. Thanks for any help.
[quote]does session mean interactive session, as distinguished from code that’s separately compiled and linked against ROOT?[/quote]No difference. This is just meant as ‘one execution’ of a program linked against the ROOT libraries.
[quote]For example, is it true that a user-created class can have a TH1 data member and not worry about double-deletion if one calls[/quote]Yes (well at least as far as the automatic registration of histogram with their TFile).
[quote]The global variable gDirectory will still own user-created trees and events though, correct?[/quote]Yes. We have not yet update the code and interface to make this optional.
[quote]So presumably a user-defined class ought to have only member references/pointers to trees/events (and not instances of them)? [/quote]Doing so is probably simpler but not compulsory. Even-though a TFile owns its TTree, it is a share ownership. If you delete the TTree before the TFile is closed or deleted, the TFile will be informed and will not delete the TTree a second time. Also if you register your object(s) in the list gROOT->GetListOfCleanups(), they will be informed (via a class to their function RecursiveRemove) of a deletion by some other object (yes, legacy shared ownership implementation).
[quote]And this is always true for TCanvases, which can never be owned by the user, right?[/quote]Yes, they can. The deletion of the canvases (by gROOT) is done only at the end of the process. If you delete them before hand, then the list in gROOT will be informed.