Christoph Borgmeier wrote:
>
> On Fri, 15 Jan 1999, Valery Fine wrote:
>
> > On 15 Jan 99 at 19:04, Christoph Borgmeier wrote:
> >
> > > class A: public TObject
> > > {
> > > public:
> > > A();
> > > ~A();
> >
> > > A* f;
> > > ClassDef(A,1)
> > > };
> [...]
> > The stack you presented shows there is a "well known" bug in your
> > class dtor. It is named "memory leak". This leak is originated by your class
> > dtor, sorry.
> [...]
>
> Hello,
>
> yes, that's the problem of simple examples. They can be very misleading in
> the parts you don't focus on.
>
> I'll try to explain one slightly simplified real-world example: There is a
> Monte-Carlo event with O(8000) MC-tracks. The reconstruction program finds
> O(20) (most of the MC-tracks do not pass detectors). I would like to do
> some analyses on the reconstructed tracks, and I am only interested in the
> few MC-tracks associated with them. I also want to see their parents.
>
> I have a class for reconstructed tracks, containing a pointer to their
> MC-track. The MC-tracks have a pointer to their parent. If the set of
> reconstructed tracks is stored in a branch, it stores exactly the
> MC-information I am interested in.
>
> Note, that this association does not mean ownership. When deleting an
> MC-track, I cannot simply delete its parent, since there are more pointers
> to it in other objects. What I have to do is to recursively follow all
> pointers and save them in a hash table, and delete them in the end. Since
> it would be unconvenient to have special treatment for all of these
> classes (and future extensions), I decided to find the pointes via the
> Root run-time type information. This allows to clean up any type of
> objects in the event graph.
>
> Of course, such a clean-up takes some time. It would be much more
> efficient, if Root would create such a hash table while creating the
> objects. There should be the possibility to delete them in the same
> transparent way as they are built.
>
> Just to be sure: This example is simplified, too. I know this special
> problem can be solved differently. I only want to show that there is a
> different level of transparency in the creation and deletion of non-split
> branch objects.
>
> Best regards and thank you for your answers
> Christoph
>
Hi Christoph,
The solution to your problem is to use a reference count in your
objects.
Instead of doing:
reference = object;
do
object->SetReference(TObject *reference)
where you create a SetReference function incrementing the reference
count for this object
+ reference = this;
In your object destructor, delete the object only if the reference
count is one.
Rene Brun
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:28 MET