Boost logo

Boost :

From: Toon Knapen (toon.knapen_at_[hidden])
Date: 2002-08-30 15:37:47


On Friday 30 August 2002 10:01, Rob Stewart wrote:
> From: Toon Knapen <toon.knapen_at_[hidden]>
>
> > On Friday 30 August 2002 09:30, Rob Stewart wrote:
> > > From: Carlo Wood <carlo_at_[hidden]>
> > >
> > > > b) The interface needs to allow one to provide an allocator<> to
> > > > use internally for (temporary) allocations (strings and
> > > > internally used STL containers).
> > >
> > > Why isn't the default appropriate? As long as your code
> > > allocates and destroys its own memory, it's memory allocations
> > > will not need to interact with those of your callers.
> >
> > but you might want to get some memory-space from the application that you
> > can use to quickly create and destroy temporaries. An allocator would be
> > a good solution. The application can also provide an interval of
> > addresses in memory that can be used by this component for doing
> > placement-new's.
>
> I still don't see the point. The library code can allocate and
> deallocate memory as it sees fit. It can use new/delete,
> std::allocator<...>, or whatever. As long as the library doesn't
> allocate memory and hand it off to the caller, or if the memory
> allocation is managed in an object that defers to the library to
> release it, there is no problem.

First, every new involves a system call so if you do a lot of new's you're
better of first allocating a memory pool (only one system call) and using
placement new to create/destroy many small objects.

The application might not like it that every library is going to allocate its
own pool, it's better to have one big pool that can be used by all libraries.
This minimises memory scattering (I'm not sure about the correct english
term, it's just if you have many small holes in your memory and you are
allocating new big objects, you're going to lose a lot of memory space ;
which is important for memory-hungry applications like scientific simulation
codes)


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk