If the array is filled with classes of a single type you might look at TClonesArray (you'll save having to delete, and gain on reallocation.) Brandon ----- Original Message ----- From: "Alberto Pulvirenti" <alberto.pulvirenti@ct.infn.it> To: <roottalk@pcroot.cern.ch> Sent: Monday, November 26, 2001 3:15 PM Subject: [ROOT] TObjArray (an generally collection's) trouble > Dear all, > > let's see if there is someone who knows ho to explain it to me... > > I created a class, with a data-member which is a TObjArray (I tried all > kinds of collection, but without any imporvement, so I decided to use > this one for the facility of the array-like syntax); > > This data-member must work this way: > 1) be filled with a large (~2000) number of heap objects, instances of > another class of mine; > 2) do some work changing the datamembers of these elements > 3) save some results to a fstream file > 4) be erased > 5) again from 1 (for a certain number of steps) > > Now, it seemed to me that, when clearing (with the Delete() method) and > refilling the TObjArray with another ensemble of new instances, i > doesn't delete the existing object, even if I order it to do that. > > The result is that, when I mare a marco run, where it uses this class > and performs its work, I get into an enormous memory leak (~800 Mb). > I proved to run it with only a loop of cration-work-destruction, in the > case where the TobjArray is filled with the largest number of objects, > and I don't reach this enormous amount of memory use, so I'm reasonably > sure that the problem arises from the task of filling-deleting-refilling. > > Is there some suggestion about? > > Regards, > > Alberto > > P.S. > Two things I need to say: > 1) i tried the same work with nearly all the collection objects of this > kind (THashTable, TList, TOrdCollection) > 2) the class of the "contained" objects, has two data-members which are > pointer to TObject heirs which are stored in another TObjArray. Could be > this the problem? But it sounds strange... >
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:51:09 MET