> To be serious, I would like to mention that ROOT is not memory leak safe The only application is memory leak safe, which does not create and delete objects at all > experience. So the garbage collector should come and save the world :) Garbage collection does not solve memory leaks. ZEBRA was based on garbage collection, but it was not memory leak safe. Victor Anton Fokin wrote: > > Well, I think ROOT (as well as C++ itself, ref. Straustrup) needs a good > garbage collector, otherwise you may spend all your time trying to > understand what, where and when to delete :) Yes, I am lazy and I hate > writing destructors and looking for correspondence between new and delete > ... So from my point of view this is a kind of useless discussion :)) > > To be serious, I would like to mention that ROOT is not memory leak safe > itself, there were many discussions on the roottalk and I also have my own > experience. So the garbage collector should come and save the world :) > > Best, > Anton > > -----Original Message----- > From: owner-roottalk@pcroot.cern.ch > [mailto:owner-roottalk@pcroot.cern.ch]On Behalf Of Krzysztof Wozniak > Sent: Thursday, February 17, 2000 3:12 PM > To: Vincent Colin de Verdiere > Cc: Root talk > Subject: Re: autodeletion of member or arrays, list... ? > > On Thu, 17 Feb 2000, Vincent Colin de Verdiere wrote: > > > Hi Rooters, > > > > Currently, from what I have seen, if I have a TObjArray* A, when I delete > > it, its members are not deleted unless I run A->Delete() before. The same > > applies to lists. I wonder if it would be possible to add some "adoption" > > mecanism which would give the responsibility of destroying objects to the > > array when it is deleted. > > > > Then for deletion, people would only need to delete the array.. It saves > > one line of code ! ;-) and it costs several lines in the array class plus > > a boolean value to activate this behaviour. ;-( > > > > But, the main point is that it would save, to my view, a lot of memory > > loss mistakes: > > when you set a new value to a bin of the array. A.At(x, i) would delete > > previous object if present. It has a cost and should not be set by default > > but is very usefull... I have used to it in another "somewhat" similar > > system and it was very pratical ! > > > Yes, it can be practical in the case, when you put the object to > ONLY ONE TObjArray. However, if the same object is stored in two > (or more) arrays, then after deleting the first array with all > objects attached to it, trying to access elements of the second array > or during deleting the second array you obtain a nice seg. val. error > :-((( > To prevent such behaviour you have to type much more than a single line > A->Delete(); > > So may be it's better to keep the present implementation? > > Krzysztof > > -------------------------------------------------------------------- > Email: Krzysztof.Wozniak@ifj.edu.pl phone: 48-12-633-3366 > WWW: http://www.ifj.edu.pl/~wozniak fax: 48-12-633-3884 > Institute of Nuclear Physics, ul. Kawiory 26A, 30-055 Krakow, Poland > -------------------------------------------------------------------- -- Victor M. Perevoztchikov perev@bnl.gov perev@vxcern.cern.ch Brookhaven National Laboratory MS 510A PO Box 5000 Upton NY 11973-5000 tel office : 631-344-7894; fax 631-344-4206; home 631-345-2690
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:19 MET