[EMAIL PROTECTED] 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. _______________________________________________ Help-gplusplus mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gplusplus
