std::allocator and underlying allocators

[Stefan Olsson]

Matt Austern wrote:

> On Jan 23, 2004, at 12:18 PM, Loren James Rittle wrote:
>
>> I will state MHO.  Any allocator, to be made the default, should
>> support the above construct internally.  The reason is that people
>> will compile their application normally against the default allocator.
>> We want to ensure that people can always disable memory caching within
>> the library.  Also, many people have tools which directly hook to
>> malloc/new, free/delete to look for programming errors.  The use of a
>> pool hides various application-level testing developers could
>> otherwise do.
>
>
<snip>

>
> So given that std::allocator should be fixed, we've got
> two alternatives.
>
> (1) Get rid of the notion of an underlying allocator, and
> just implement allocator on its own.  In principle I like
> this idea; it maintains a clear separation between the
> standard and extended parts.  We'd have to decide
> which technology we want to use for the default, of
> course: the existing pool allocator, or the bitmpaped
> allocator, or whatever.
>
> (2) Continue to use the idea of an underlying allocator,
> but use a standard interface instead of the SGI one.
> So we'd have to fix pool_allocator.h to provide a
> standard interface, and then change allocator.h so
> that it uses a standard interface.  Mildly ugly, but quite
> doable.
>
> Thoughts? 

My two cents on this topic is that the first step would be to change the 
interface to pool_allocator to a standard one. This would have no impact 
on users that don't want to bother at all with the possibility of 
changing allocator (no changes to code or performance).
Users that like to test/use other allocators should be "tought" to use 
the standard syntax for defining allocators instead of the SGI one.

In the long run I guess that the default pool allocator could be 
replaced, but as long as the documentation clearly states each 
allocator's (including the default pool) pros and cons I think that this 
should be left to the users to decide on a per application basis.

Brgds

/Stefan

>
>
>             --Matt
>