Hello, I should have been more clear. The object statistics root keeps apply only to root objects, that is objects that inherit from TObject. For your objects that don't inherit from anything, you are on your own as far as I know. If you go ahead and do what you suggest, you will be reinventing in a crude (perhaps elegant if I am underestimating) way what the root guys do for the objects that inherit from TObject. Your message implied that you don't have the statistics for root objects created inside other objects. If that is really the case, I really don't understand. When an object that inherits from TObject is created, gObjectTable->AddObj(this) is executed inside the TObject constructor if fgObjectStat is defined which is triggered by setting the ObjectStat in the .rootrc file. Kris "Peter H. L. Christiansen" wrote: > Hi Flemming, Kris, Anders and all you other g..(.)s > > It is clear to me that I don't fully understand the concept of ownership, > I will have to do a little study. > > It was very helpful for me to get Kris comment, but (propably because of > ownership;) I can only see the objects in my program ( Where I found a > mess ) and not the objects created inside other objects, so I still think > it would be nice to have these static variables for debugging. > ( It is a big experience to watch 40,000 BrVirtualTrack vanish ;) > > I found the leak in the BrTrackFollowFinder which I myself had introduced > and will remove it soon. > fTrackGroups->Clear(); should be fTrackGroups->Delete(); > > Now it seems that there are no more leaks at least I can do a lot of > tracking ~ 100 * multiplicity 2-60 ~ 180.000 tracks in TPM1 without > any sign of ruining my memory. (digitization, clustering, and tracking). > > > I guess you don'nt need the > > > fClusterTable = 0; > > since thenobject is deleted anyhow. > > I started doing this since I read in my c++ manual that it was nice to do, > so you don't have the pointer pointing to junk, but it might be, that it > is done automatically. I don't know. > > > > You have to delete the seq. By adding the address cluster will come in two > > flavours > > - the single clusters that have the input sequences. (owned by event_node) > > and > > - deconvoluted new sequences that thus would be owned by the cluster. > > > > To make the ownership clear a copy was made. > > OK > > > > > > -- Do you have the most recent changes by Trine who worked on these methods? > > > Propably not, I will update soon since it seems that I no longer need my > messy brat version. > > Thanks for the useful comments > Peter
This archive was generated by hypermail 2b29 : Wed Jun 14 2000 - 19:08:27 EDT