Problem with delete[] in class destructor

[Eljay Love-Jensen]

Hi Nicolas,

>I'm watching the memory consumption with 'top' (that's the reason for the call to sleep)

Top does not monitor "free space versus consumed space" in your program's heap.

A different compiler (SAS/C++) gave me an API that I could interact with the heap in my program, asking it such questions as "How many OS extants do you have?", "How big is the extant?", "How much heap free space is in the extant?"  And a few knobs to adjust where small allocations versus large allocations go.

I don't know if the Standard C Library provides an API for interacting with the heap manager -- I presume it does not.

There are alternative heap managers that have different performance characteristics, some of which give the programmer more control over heap behavior -- including when an extant is returned to the OS.  That'd be for OS's such as Mac OS Classic, OS/2, Amiga OS, Win16 applications.  Other OS's, such as Unix-based ones, provide each application a virtual memory space up to their ulimit parameters.  (I haven't looked into the underpinnings of Win32 applications under NT -- I don't know if heap management is done via extants, or done the Unix ulimit way.)

>What's weird is that if I launch the original program a second time while the first already has supposedly freed its memory, it eats everything and bring my box to its knees, killing most of the processes that use memory (so I guess the memory is not freed at all).

I presume you are seeing the behavior of swap space being utilized.

You should use ulimit, to prevent a process from consuming too much space.

>Also, top tells me that the whole memory stays resident (which means it doesn't even return to the program's free memory pool, am I right?)

No.  Top does not monitor the free memory pool.  The resident memory is not a reflection of free or consumed space in the heap.  It's whether the memory is resident (in actual RAM) or swapped (paged out, via the magic of the PMMU).

HTH,
--Eljay