Re: Custom new/delete and STL

[Matthias Doerfel]

starkos@gmail.com wrote:

> I am trying to integrate a third-party library into an existing
> project. All memory allocations must be routed through a custom
> memory manager (not my choice). 

Without knowing your special memory manager this is not always a bad
idea. We are using a memory manager for objects shared between
processes via IPC/SHM. And these objects contain STL containers,
managed also by the memory manager.


> On the Windows port, I overloaded new() and delete() and everything
> is fine. So long as all STL objects go out of scope at the end of
> the session every memory allocation has a matching release.
> 
> On the Linux port, this is not the case. I see calls to new() with
> no matching call to delete(). 

Hm, I've not seen this behavior. This is the way we go, initially
starting with Linux:

- As you said, overload new()/delete() of your classes to use the
other memory manager.

- The STL container itself needs also to manage its internal data with
the memory manager. For this one uses the concept of an "STL
Allocator". Google for "stlallocator" or see Stroustrup, C++, chapter
19.4 Allocators (german edition at least).

- Then create your list:
  typedef list< ShmClass*, ShmAllocator<ShmClass*> > ShmList;
Now this list completely holds its data in shared memory.

- At last put the list head itself under control of the memory
manager, perhaps by being a member of another class with overloaded
new()/delete().


> I'm still looking through the source code -- I am not an expert on
> GCC or Linux for that matter by any means. 

Source code inspection of STL was not done. But the second part does
really help.


> Am I right? Is that the case, or is memory being released via some
> other method? Although I can probably guess at the answer, is there
> a way force the g++ STL to match up the new/deletes? I checked the
> FAQ but didn't see anything. This is for GCC (3.3.5).

new() and delete() should always match, but what you see is perhaps
the management data of the list itself.


Hope this helps,
Matthias.