Sebastien,
When you do
TBranch *branch = tree->GetBranch(...);
you get a pointer to the branch object in the current Tree. This pointer
will become obsolete as soon as you
move to the next Tree in the TChain.
Rene
09/03/2011 15:13, Sebastien Binet wrote:
> On Wed, 9 Mar 2011 14:50:39 +0100, Rene Brun<Rene.Brun_at_cern.ch> wrote:
>> Sebastien,
>>
>> I am surprised by this remark. A TChain is a TTree but a TTree is not a
>> TChain.
> which remark ?
> this one ?
> '''
> (I was careful to check the methods I was calling on the TTree
> were virtual ;))...
> '''
>
> I was merely stating that, relying on the TTree interface, I could
> leverage the usual polymorphism-fu via virtual calls and still get the
> correct behaviour if 'init_branches' was given a TChain pointer.
>
>> If your case it worked for the first Tree in the TChain because this
>> Tree was already loaded at the time of the call.
>> I strongly suggest to use a TSelector based analysis instead of
>> reinventing once more the wheel ::)
>> This will take care of the changes of files and Trees in the TChain and
>> in addition you will be ready to run on parallel architectures too.
> yes, but my use case is not really writing an analysis code but
> integrate the ROOT event loop with the Athena one (and check the
> performance numbers w.r.t. percolating through POOL)
>
> and we (athena/gaudi) have also some code for parallel architectures :)
>
>
> Philippe,
>
> > Any action done directly to a TBranch object is explicitly lost
> > because the liftetime of the TBranch objects is exactly the same
> > as the TTree object (i.e. and the same as each file in the TChain).
>
> ok, thanks.
> I guess a TBranchChain doesn't make sense, performance-wise.
>
> -s
>
Received on Wed Mar 09 2011 - 15:23:26 CET
This archive was generated by hypermail 2.2.0 : Wed Mar 09 2011 - 17:50:01 CET