Hi Bill,
Your constructor is correct. You do not have to change it.
However, you should notice the following in case your class StLaserEvent
is one branch of a Tree.
Let's assume the following logic:
StLaserEvent *event = 0;
tree.SetBranchAddress("event",&event);
for (Int_t i=0;i<nentries;i++) {
tree.GetEntry(i);
// do some work with your class
}
Up until version 3.0 included, TTree::GetEntry was calling
the event destructor at each iteration. The default for the branch
was SetAutoDelete(kTRUE).
In version 3.01, we changed the default (see Release notes)
to SetAutoDelete(kFALSE). With this default the event destructor is
not called anymore. Instead GetEntry reuses the previous object event
and calls the destructors only for the members that are pointers
to objects. This may reduce considerably the number of calls to
constructors and destructors. If you want to use the previous logic,
simply call SetAutoDelete(kTRUE) for your top branch.
Assuming that you want to run with the new default (I strongly encourage
you to do it (see why below), you must make sure that your class
can operate in this mode. Coming back to your particular example,
my guess is that your StLaserEvent.h file is something like:
class StLaserEvent : public TObject {
TClonesArray* fTracks;
TClonesArray* fHits;
TClonesArray* fPixels
static TCLonesArray* fgTracks;
static TClonesArray* fgHits;
static TClonesArray* fgPixels;
};
With the new scheme, the same object event will be reused between
entries. GetEntry will happily call delete fTracks, delete fHits, delete
fPixels. UNLESS, you instruct it to not do it. How ? Modify your header
file in the following way:
class StLaserEvent : public TObject {
TClonesArray* fTracks; //->
TClonesArray* fHits; //->
TClonesArray* fPixels //->
The "->" in the comment field of a data member indicates to the ROOT I/O
system that:
- it can call fTracks->Streamer(buf) instead of buf << fTracks
(this is much faster and you also save space in the file)
- it should not delete fTracks
In other words, it assumes that fTracks is always pointing to an object
that it should not destroy. This is documented since many months in the
Users Guide.
WHY DID WE IMPLEMENT THIS NEW SCHEME ?
=======================================
We see more and more (justified) demands to be able to process
a ROOT Tree without having the original classes (in your case
StLaserEvent). When the split mode is used, you can make very complex
queries involving ONLY the data members of the classes. You do not call
any member function of the classes. To allow this kind of operation,
we clearly cannot assume that a constructor or destructor (not available)
is called.
So, my recommendation is to instrument your class such that this mode
of operation becomes possible.
In summary, in your case, you have two options:
OPTION1
======
- you get the old behaviour where your StLaserEvent destructor is called
at each entry as well a call to the constructor.
- To get this option call mytopbranch->SetAutoDelete(kTRUE)
OPTION2
======
- Use the new default (SetAutoDelete(kFALSE) and instrument your class
with the "->" for all members like TClonesArray or when you do not want
the pointed object to be deleted/recreated at each entry.
Rene Brun
On Tue, 11 Dec 2001, William Love wrote:
> Rene
> Valery thinks my trouble may be related to the constructor of
> my classes. Can you tell me how the following code is wrong?
> Bill
>
> _
> StLaserEvent::StLaserEvent()
> {
> // Create an StLaserEvent object.
> // When the constructor is invoked for the first time, the class static
> // variable fgTracks is 0 and the TClonesArray fgTracks is created.
>
> if (!fgTracks) fgTracks = new TClonesArray("Track", 1000);
> fTracks = fgTracks;
> fNtrack = 0;
> if (!fgHits) fgHits = new TClonesArray("Hit", 1000);
> fHits = fgHits;
> fNhit = 0;
> if (!fgPixels) fgPixels = new TClonesArray("Pixel", 1000);
> fPixels = fgPixels;
> fNpixel = 0;
> }
>
> ----- Original Message -----
> From: "Valeri Fine" <fine@bnl.gov>
> To: <roottalk@pcroot.cern.ch>
> Sent: Monday, December 10, 2001 10:56 PM
> Subject: [ROOT] Some I/O constrains: Re: ROOT] LAST CALL for comments before
> closing ROOT version 3.02
>
>
> > Hello Rene,
> >
> > Bottom line:
> >
> > --------------------------------------------------------------------------
> -----------------
> > ROOT doesn't allow to assigned any value to the class pointers but
> zeros
> > with the class default ctor.
> > --------------------------------------------------------------------------
> -----------------
> >
> > I've found a reason for one of the crash reported today.
> > This is due a new ROOT I/O schema imposes some new constrain.
> >
> > In this particular case the ctor of TVolumePosition class
> >
> http://root.cern.ch/root/htmldoc/src/TVolumePosition.cxx.html#TVolumePositio
> n:TVolumePosition
> > contains a statement:
> >
> > if (!fMatrix) fMatrix = TVolume::GetIdentity();
> >
> > This is to assign a pointer to the static Identity matrix in case it is
> not provided by
> > the user code.i.e it is a default value !!! and this value is NOT zero.
> >
> > What happens when the object is read by the new ROOT i/o layer.
> >
> > 1. It instantiates TVolumePosition calling its default ctor.
> > As result fMatrix is assigned to the static object pointer "by
> default".
> >
> > 2. ROOT does apply a "delete" statement to all pointers of the new created
> object.
> > "Usually" all pointers are still zero and cause no big problem.
> >
> > 3. In this case the pointer fMatrix points to the static stack object. It
> is
> > NOT zero and "delete" causes the program crash.
> >
> >
> > So the bottom line:
> >
> > --------------------------------------------------------------------------
> -----------------
> > Default ctor is not allowed to assigned any value to the class pointer
> but zeros.
> > --------------------------------------------------------------------------
> -----------------
> >
> > Now the question is it "by design" and my class should be redesigned or
> > the problem could be fixed ?
> >
> > What about Bill Love's TTree troubles I suspect his class has "not right"
> ctor as well.
> > I'll check this tomorrow.
> >
> > With my best regards, Valeri
> >
> >
> > -----
> > Dr.Valeri Fine
> > STAR/US Atlas E-mail: fine@bnl.gov
> > Brookhaven National Lab Phone: +1 631 344 7806
> > Upton, NY 11973-5000 FAX: +1 631 344 4206
> > USA
> >
> >
> >
> > ----- Original Message -----
> > From: "Rene Brun" <brun@pcbrun.cern.ch>
> > To: "Valeri Fine" <fine@bnl.gov>
> > Cc: <roottalk@pcroot.cern.ch>
> > Sent: Monday, December 10, 2001 5:03 PM
> > Subject: Re: [ROOT] Re: ROOT] LAST CALL for comments before closing ROOT
> version 3.02
> >
> >
> > > Hi
> > >
> > > On Mon, 10 Dec 2001, Valeri Fine wrote:
> > >
> > > > Hello Rene,
> > > >
> > > > > We intend to release Root version 3.02/06 this week. This will be
> the PRO
> > > > > release.
> > > >
> > > > He have discovered several problems with the last version of ROOT
> from CVS
> > > >
> > > > 1. We can not read back our files written half year ago (with ROOT
> 3.00.06)
> > > > We have not had any problem to read them with ROOT versions
> 3.02.00 / 01
> > >
> > > Could you be more explicit? I cannot do anything with just this info.
> > >
> > > >
> > > 2. We
> > > can not use TChain to read several TTrees' in row (See Bill Love's
> report)
> > > > The macro crashes occasionally
> > >
> > > I am waiting from Bill a session where he can reproduce the problem.
> > >
> > > >
> > > 3. We can not read the new files with TVolume objects,
> > > > but we can read the old versions of there files though.
> > >
> > > TVolume has not been modified in version 3.02.
> > >
> > > >
> > > > We are working to understand the reasons of these new problems and
> will appreciate you
> > > > will wait a little with your release.
> > >
> > > Why are you reporting these problems only now?
> > > >
> > > > Have you any idea what has happened with ROOT i/o recently, that may
> have affected the
> > > > backward compatibility ?
> > >
> > > So far, you are the only one complaining. If there are other people with
> > > the same experience, please let me know.
> > >
> > > When you encounter an I/O problem, I suggest the following procedure:
> > > Set gDebug=2; before reading or writing. The I/O functions in
> > > TStreamerInfo
> > > will print one line for each data member of a class being read/written.
> > > It also shows the persistent class definition. This should help you
> > > to localize the problem.
> > >
> > > Rene Brun
> > >
> > >
> > > >
> > > > With my regards, Valeri
> > > > -----
> > > > Dr.Valeri Fine
> > > > STAR/US Atlas E-mail: fine@bnl.gov
> > > > Brookhaven National Lab Phone: +1 631 344 7806
> > > > Upton, NY 11973-5000 FAX: +1 631 344 4206
> > > > USA
> > > >
> > > >
> > > >
> > > >
> > >
>
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:51:11 MET