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 -- 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
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:28 MET