I may be naive about such things but I believe one should be very careful
about using the "new" operator in C++. It should only be used to
dynamically create a new instance of an object in memory and then it has to
be explicitly removed using the "delete" command otherwise memory leaks
ocurr. It is not required to use "new" when creating a new instance of
something.
For example
DKHobj MyDKHobj;
and
DKHobj *MyDKHobjptr = new DKHobj;
both produce an instance of the object DKHobj (whatever that is) but the
first form is automatically deleted when it goes out of scope but the
second form must be explicitly deleted by the command
delete MyDKHobjptr;
If the delete command is not present or the pointer is lost because you go
outside the scope of MyDKHobjptr then the memory space is never released.
So be sure you need to use dynamic memory allocation and then be sure that
you delete it when you are done and that the program can't bypass the
delete statement even with interrupts, breaks, error returns, etc.
--On Tuesday, September 17, 2002 4:10 PM -0400 zhangchi
<zhangchi@general.lns.mit.edu> wrote:
>
> Hi everyone,
>
> Last Thursday, after my computer started to swap, I decided that I wanted
> to do something about the resource leak in BlastLib2. There were a lot of
> memory blocks allocated by new yet not released by delete.
>
> Here are a few things I did:
>
> 1. I wrote destructors for a few classes to delete the heap objects.
>
> 2. Especially I wrote a destructor for TEventDisplay in nsed.cc. used
> auto_ptr in some places to return memory after exiting.
>
> 3. I added private copy constructor and assignment operator = to some of
> the classes. This will forbid a few things:
> copy: T t1; T t2(t1);
> assign: T t1; T t2=t1;
> pass by value: f(T t); must use: f(T& t) of f (T* t)
>
> the 3rd one may affect some codes you wrote. For instance constructors of
> TBLDetRecon and TBLScRecon are slightly modified.
>
> So far, except for a few TFiles and histograms in TBLFitTrack and
> TBLDetRecon, all objects located on heap by new are removed using delete.
>
> Since the changes involve memory manipulation, if the code crashed by any
> chance, please let me know, and I am more than willing to debug with you.
>
> By the way, please please do not write statements like this anymore:
>
> fCheckAnal[5] = new TGCheckButton(fG2, new TGHotString("Stubs"), -1);
>
> the TGHotString is doomed to be a memory leak, it does not give anyone
> any chance. At least, we should leave a handle such that delete could be
> used safely later.
>
> Unfortunately, I could not make it to the meeting tomorrow.
>
> Chi
>
>
>
Cheers,
Douglas
26-415 M.I.T. Tel: +1 617 258 7199
77 Massachusetts Avenue Fax: +1 617 258 5440
Cambridge, MA 02139 E-mail: hasell@mit.edu
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:28 EST