This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: multimap.clear() does not free its memory


If you do a google search for using allocators with STL, there's a
multitude of info.  You can tell STL to use the "new allocator" or the
"malloc allocator"... though I'm not sure if these are standard or
not.  If they're not standard, I believe that stlport has them. 
Sorry, it's been a while.

Also, the standard makes a provision that you can provide your own
allocators, if it is that important.  There are several good pool
allocators available online that you could use.  You might look at the
boost library for example.

  Brian

On Apr 8, 2005 2:56 PM, Toon Knapen <toon.knapen@fft.be> wrote:
> Brian Budge wrote:
> > The default allocator for the standard library (STL) stuff is
> > implementation dependent.  That means it won't necessarily use the
> > same memory pool as operator new.  Moreover, even within any given
> > pool, depending on the implementation, the implementor might decide to
> > allocate memory for different scenarios.
> >
> > You'd probably have reasonable luck
> > allocating/deleting/allocating/deleting with operator new and/or the
> > stl's allocator, but not necessarily when you mix the two.
> 
> But my problem now is that in some application I'm creating a
> 'temporary' std::multimap which takes about 500MB. But now I want to
> make sure the application is going to reuse this memory later during the
> lifetime of the app (but not necessarily for stl objects) because
> otherwise it might run out of memory.
> 
> toon
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]