multimap.clear() does not free its memory

[Toon Knapen]

Brian Budge wrote:
> Hi Toon -
> 
> Yeah, since I posted, I also noticed somewhere or another that the
> default now is to use new.  

Well looking at 
http://gcc.gnu.org/onlinedocs/libstdc++/20_util/allocator.html indeed 
confirms that the default allocator uses new but not every time one 
calls the allocate member of the allocator (because it creates its own 
pool).

The doc also states that I can define the env.var. GLIBCPP_FORCE_NEW but 
this does not seem to have any effect. Using an allocator like
std::__allocator< T, std::__new_alloc> does have a big effect though.


> I guess it's been a little while since I
> looked at the internals... sorry about the missinformation there. 
> However the stuff about the pools is still valid, and might be a way
> to solve your problem.
> 

Currently my problem is that I want to know the total memory consumption 
at every stage in my application (which is a simulation of the acoustics 
of an engine using finite-elements). During the lifetime of the app we 
allocate big containers, free them and later on again allocate big (not 
necessarily stl-) containers again. Since we're generally using all 
available memory I need to know what we 'really' consume in every stage 
during the run. The pools complicate having a clear view on the mem 
consumption at a specific moment in time (and valgrind report the pools 
as being memory-leaks). Additionally the mem-pools that are used (under 
the hood) by gcc might even have a negative effect on the available 
memory. Using the boost::pool_allocator might indeed be a good idea.

toon