Hi Rene, Now I'm confused. You tell me I _should_ call RemoveAt/Compress for a TClonesArray in a Tree; but this is what I do and according to the reasoning below It cannot work. Or was it a typo and your advise is I _shouldn't_ use RemoveAt/Compress for a TClonesArray in a Tree?. I just want to make sure. If I _should_ call RemoveAt/Compress. I would appreciate an explanation about why my logic below is wrong. Thanks for the quick answer, Manuel El vie, 05-07-2002 a las 17:25, Rene Brun escribió: > Manuel, > > You should call RemoveAt/Compress for a TClonesArray in a Tree. > This is the assumption behind ExpandCreateFast. > This should be made clear in the doc. > > Rene Brun > > > On 5 Jul 2002, Manuel [ISO-8859-1] Sánchez García wrote: > > > Hi, > > > > Could anybody tell me what's wrong with the following reasoning? > > > > Let's say we have TClonesArray in a TTree. In my eventLoop I call > > RemoveAt and then Compress(). Now, RemoveAt() doesn't free the memory in > > fKeep->fCont[i] but calls the destructor; now the virtual table pointer > > points to that of one TObject. (This can be checked directly on the > > interpreter) > > > > Now, next event comes. In the TBranchClones::GetEntry a > > ExpandCreateFast() is done; this expands the TClonesArray and prepares > > it to dump the data from the branch. Now for each element 'i' in the > > array 2 things may happen > > > > 1.- fCont[i]==0 && fKeep->fCont[i]==0 => the object is created and > > the default constructor called. This is fine > > > > 2.- fCont[i]==0 && fKeep->fCont[i]!=0 -> The constructor is not > > called; but if the object's destructor was called in advance the virtual > > table is not correct. > > > > This problem doesn't show up when only TClonesArray::Clear() is done > > because that doesn't involve calling destructors. > > > > Is this a bug or am I missing something? > > > > Best regards, > > Manuel > > >
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:59 MET