Re: Possible problem ? *** Seems to be real ! ***
Rene Brun (Rene.Brun@cern.ch)
Wed, 19 Aug 1998 10:02:42 +0200
Nick van Eijndhoven wrote:
>
> > > Dear ROOTers,
> > > In setting up some classes for data analysis of events concerning
> > > heavy-ion collisions I wonder about the following :
> > >
> > > I have a class Track and a class Jet and my event data consists
> > > of a ROOT Tree in which there is a branch for tracks and a branch
> > > for jets of a certain event.
> > > Both Track and Jet contain a data member float fEnergy
> > > In case I have the libs containing the Track and Jet classes
> > > available in my ROOT environment there clearly is no problem,
> > > since I can just use the Track and Jet member functions to investigate
> > > e.g. the fEnergy of both of them and even plot one against the other.
> > > However, in case I don't have the libs, I would use the MakeCode()
> > > facility to be able to analyse the Tree.
> > > As far as I can see this now gives a problem, since the fEnergy
> > > would be related to both classes.
> > > Question : Am I right here that the produced code can't work ?
> > > Or does MakeCode properly take care of the problem ?
> > >
> > > Obviously a way out would be to define fTrackEnergy and fJetEnergy,
> > > but as far as I can see this is no solution once one thinks of
> > > (re)using code of other related experiments.
> > >
> > > Suggestion : In case MakeCode encounters the same variable name
> > > in different branches, could then on each additional
> > > occurence of that variable some suffix be added auto-
> > > matically be MakeCode ?
> > >
> > > In case of the above situation this would result in e.g. :
> > >
> > > fEnergy and fEnergy_2
> > >
> > > In case the problems I expect in the above are real, the latter
> > > is just a suggestion and in case someone has a better solution
> > > please let me know.
> > > --
>
> Hi Axel and fellow ROOTers,
> I was just trying a few things out and it seems the problem I
> expected is really there (unless I do something wrong, in which
> case I would like someone out there to tell me that).
> Below I will attach a small macro (pbdata2.cc) in which I create
> a Tree which has 3 branches.
>
> branch 1 = evhead which is a simple struct
> branch 2 = ledaup which is an AliCalorimeter object
> branch 3 = ledalw which is an AliCalorimeter object
>
> Clearly branch 2 and 3 have the same data members etc... defined,
> but for ledaup the number of rows(i.e. fNrows) is 44 whereas this
> number is 40 for ledalw.
> When I run the macro (ROOT 2.00/08 on Win95) which reads some data
> from an h2root converted cwn, fills my struct and AliCalorimeter objects
> and writes the output into a Tree, indeed an output Tree is created
> on a file (see the attached pbdata2.log for the produced log file).
> As you can see here, indeed the ledaup has 44 rows and ledalw has 40
> rows.
> BUT .....
> >From the tree->Print() output I get the impression that the fNrows
> from ledaup and ledalw are just somehow mixed, since I see 2 times
> a branch fNrows instead of ledaup_fNrows and ledalw_fNrows.
> To investigate this, I startup a ROOT session and investigate the
> tree in my browser.
> There I nicely see the branches
>
> evhead
> ledaup
> ledalw
>
> and indeed for each branch the various datamembers are there.
> BUT ....
> When I plot fNrows of the ledaup branch I get the same result as
> plotting fNrows of the ledalw branch !
> And this is exactly what I feared in my previous mail.
>
> Question : How can I achieve that the datamembers of 2 different
> branches, containing both an object of the same class
> can be be distinguishable ?
>
> As I said before, of course I can investigate the tree using the
> AliCalorimeter memberfunctions of ledaup and ledalw, but my point
> is it should also be possible without having the classes available
> since if one takes my produced output tree file and uses the
> MakeCode() facility, things will go terribly wrong.
> In addition I would expect to be able (via the browser) to inspect
> correctly the datamembers of the various branches, even in case
> different branches contain different objects of the same class.
>
> In case I dod something wrong, please help me out on this.
> Otherwise a solution could be that datamembers of (user defined)
> classes in a certain branch get the branch name as a prefix (or suffix)
> automatically in writing the tree. Maybe one could make a new
> member function with which one could toggle this automatic prefix
> (suffix) generation for each branch separately.
> --
Nick,
In case of a class containing pointers to objects of the same class
and in split mode, the leaves of the Tree will effectively have
the same name. I will change this in a future version.
Note that, if instead of using a pointer, your data members
are directly objects of the same class, the leaf names will be distinct.
Rene Brun