It is used in the implementation of TBranchClones to implement split of objects. One of the thing we run into when trying to âhand-makeâ branch hierarchy is that the tools (MakeSelector, TTree::Draw, TBrowser, etc.) tend to assume that there is also an object/class hierarchy. It might be possible to implement what you want but I still donât have enough information about the âwhyâ you need what you need ( ) to know whether overcoming those obstacles is the best solution in the long term.
With add friend the name of the TTree is implicit part of the branch name, so no need to change the actual branch names.
Yes, that is characteristic to both between friends in a tree containing samely-named objects and between branches in a tree containing samely-named objects. But this seems to again highlight the philosophy âyou have the file as it is now, so whether or not it should been structured that way to begin with, just use friendsâ. I am trying to broaden my toolkit of methods to use with ROOT data management. Is this not enough of a reason as to why I would like see this particular method? In terms of long term concerns, does it help to know that this file will be standalone and not part of a larger framework?
It is used in the implementation of TBranchClones to implement split of objects.
I have found little in the way of how to implement TBranchClones, although your response here seems to suggest it relates to my problem at hand. Has progress been made in implementing the related topic of âmerging laterally two filesâ, or is the method still to use GetEntry and Fill?
Has progress been made in implementing the related topic of âmerging laterally two filesâ,
Unfortunately no. If/When we do it, we would go for a solution where the original structure (that the set of branch was in a given TTree) would be only âvisibleâ via the new branch names (but this would also require augmenting the existing utilities to understand this).
Doing the way you want âa prioriâ could be done by creating an empty branch, creating standalone branches, adding them to the list of branch of the parent and adding the leaves to the TTree list of leaves. But somebody else recently tried and did not quite succeed. I.e. for this to work properly, it would require enhancement of (likely) both the TBranch[Element] class and the utilities (TBrowser, MakeSelector or even TTree::Print) to understand correctly the structure.
Ah, okay. So this seems to be the problem with what I would like to do. Thank you for the feedback. If this is ever implemented, I assume it would be a highlight under the implementing ROOT versionâs release page?
I have now modified my macro from earlier to include two classes, with one of the classes a âsuperclassâ which includes objects from the other class, and the other class a âsubclassâ inheriting from TObject. I then add to my tree parent branches referenced to objects from the âsuperclassâ. The resulting structure does indeed nest branches within branches, but I am now having trouble filling the subbraches of these parent branches. After assigning values to the leaves in each subbranch, I first tried Fill() with tree. That didnât work, so then I tried Fill() for each parent branch. That also didnât work, so then I tried Fill() on each subbranch. Am I missing something like a SetEntries(), or SetBranchAddress()?
Am I missing something like a SetEntries(), or SetBranchAddress()?
Most likely set branchAddress.
with one of the classes a âsuperclassâ which includes objects from the other class, and the other class a âsubclassâ inheriting from TObject.
Note that derivation from TObject is not necessary for I/O nor for splitting.
The resulting structure does indeed nest branches within branches, but I am now having trouble filling the subbraches of these parent branches. After assigning values to the leaves in each subbranch, I
Humm ⌠how did you âassign values to the leaves in each subbranchâ ?
If using SetBranchAddress(), would I have to do it for both a parent branch and its subbranches?
Without the derivation from TObject, I get a TStreamer-related run time warning which says the subclass objects inside of the superclass wonât be saved (data member wonât be saved). Under the section ROOT I/O Requirements for Classes I get that a class needs a default constructor to store objects with ROOT. Is this not applicable to what I want to do?
To âassign values to the leaves in each subbranchâ, I write a function called by the main function which takes the class object associated with a subbranch, then assigns values to itâs member variables.