Hi Christoph,
what I do in situations like this is something like this:
----------------------------------------------------------------
in my main program:
----------------------------------------------------------------
[...]
TList *gc = new TList; // list keeping track of objects to be deleted
A* x = new A;
A* y = new A( x, 0 );
A* z = new A( 0, x );
A* a = new A( y, z );
gc->Add(x); gc->Add(y); gc->Add(z); gc->Add(a);
[...]
tree->Branch("Aname","A", &a, 10000, 0 );
[...]
gc->Delete(); // delete objects when done
----------------------------------------------------------------
Christoph Borgmeier wrote:
>
> On Thu, 2 Apr 1998, Rene Brun wrote:
>
> [...]
> > My suspicion is that you have a problem with your destructors.
> > Any object allocated by a constructor ,added to a list, things such
> > float *x, etc must be deallocated in your destructors.
> > A good way to look at memory leaks for objects is to use the
> > statement:
> > gObjecttable->Print();
> > after every event and see how the list of objects grows.
> > However this statement cannot spot leaks coming from the allocation
> > of arrays of basic types.
> [...]
>
> Hello,
>
> my problem is, that I cannot delete the pointers, since the objects do not
> own the objects they point to. My test example is
>
> ----------------------------------------------------------------
> class A: public TObject
> {
> public:
> A(): p1( 0 ), p2( 0 );
> A( A* a, A* b ): p1( a ), p2( b ) {}
> ~A();
> A* p1;
> A* p2;
>
> void Print( Option_t * );
>
> ClassDef(A,1)
> };
> ----------------------------------------------------------------
>
> in my main program:
>
> ----------------------------------------------------------------
> [...]
> A* x = new A;
> A* y = new A( x, 0 );
> A* z = new A( 0, x );
> A* a = new A( y, z );
> [...]
> tree->Branch("Aname","A", &a, 10000, 0 );
> [...]
> ----------------------------------------------------------------
>
> when I read the event created by this, x is used by y and by z. So if I
> delete p1 and p2 in ~A, I get a segmentation violation when z tries to
> delete x because it has already been deleted by y. This might seem very
> theoretical, but it just happens to be very similar to the structure I use
> to store certain decay information.
>
> My conclusion is, it would be great to have a garbage collection for such
> things. ROOT maintains the additional objects correctly, I find them in
> the gObjectTable. The only thing, which I cannot find, is a systematic
> strategy to delete the objects, which have been created on the stack by
> one TBranch::GetEvent.
>
> Is there the possibility to let TBranch::GetEvent store the additional
> object in a newly created table instead of the normal one, so that I can
> delete them when I want?
>
> best regards and thank you for the hints
> Christoph
--
Org: CERN, European Laboratory for Particle Physics.
Mail: 1211 Geneve 23, Switzerland Phone: +41 22 7679248
E-Mail: Fons.Rademakers@cern.ch Fax: +41 22 7677910
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:34:31 MET