Hi Carlos, Another way to handle the problem is to use a singleton TClonesArray manager to manage a pool of TClonesArrays. I wrote such a manager for our code. You can find it at: http://www.hep.umn.edu/~schubert/RecArrayAllocator.cxx http://www.hep.umn.edu/~schubert/RecArrayAllocator.h There is a description of its use in the header. -Sue Rene Brun wrote: > Hi Carlos, > > I recommend the creation of > static TClonesArray *fgTracks[2]; //or higher dimension > TClonesArray *fTracks[2]; > > In the Event example, we use a static TClonesArray *fgTracks. > In principle, this pointer should be in a Run class. > The point is that this array should be created only once and not > for each event to take advantage of the TClonesArray. > > Rene Brun > > On Mon, 13 Jan 2003, [ISO-8859-1] Carlos Muņoz Camacho wrote: > > > > > Hi, > > > > I'm working with an event class which is very similar to the one in > > $ROOTSYS/test/Event.h. In particular, it contains a TClonesArray* as a > > member, equivalent to fTracks in the example. > > The example uses a static TClonesArray* fgTracks to which fTracks > > points to after the constructor Event::Event() is called. > > Imagine we want to have, at the same time, two events with different > > tracks in the TClonesArray. Par example, we analyse the event in two > > different ways and this gives us different tracks, and want to keep the > > two events for comparison. This won't be possible if the fTracks of both > > events point to the same static fgTracks. > > My real question is: what is the point of defining the static fgTracks > > in the example, whereas having only fTracks seems enough for me. If > > there's a reason to do so, when are we supposed to define "static copies" > > of members? > > > > Thank you! > > > > Carlos MUŅOZ CAMACHO > > SPhN/CEA-Saclay > > > > > >
This archive was generated by hypermail 2b29 : Thu Jan 01 2004 - 17:50:08 MET