> 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
-- Christoph Borgmeier Mail: DESY F15/HERA-B, Geb. 61/117 Notkestr. 85, 22607 Hamburg Humboldt Univ Berlin Phone: +49 40 8998 4850 Email: Christoph.Borgmeier@desy.de