[v3] allocator switches

[Felix Yen]

 >  I'm not quite sure about this.
 >
 >  We've got to support both std::allocator, and ext allocators that 
can be
 >  used as _Alloc template parameters.
 >
 >  Can this be accomplished with the above design? I'm uncertain.

It depends on how literal this support must be.  In the approach I 
sketched, there would be two allocator interfaces, the standard one and 
a minimal one that probably has just two methods, allocate() and 
deallocate().  For the purpose of discussion, I'll call objects that 
have this second interface GNU-style allocators or GSA's, and assume 
that all the allocators in /ext are modified accordingly.  Now 
std::allocator becomes something like:

template<typename _Tp>
    class allocator : public __gnu_cxx::Allocator<_Tp, 
__gnu_cxx::__default_alloc>
    {/*possibly empty*/};

The parameter list depends on how allocators are configured.  In my 
example, the new Allocator template hypothetically encapsulates all 
references to GLIBCXX_FORCE_NEW, so there's no parameter for that 
information.  In real life, there would be a second GSA parameter to 
support large requests (e.g. buffer allocation), and the template would 
encapsulate the logic to determine which GSA to use based on request 
size and a configuration technique to be determined (another 
environment variable?).  This second GSA would probably be 
new_allocator, but users may want to use malloc_allocator or 
debug_allocator instead.

In this approach harnessing another /ext (GNU-style) allocator entails 
defining another template, e.g.

template<typename _Tp>
    class sgi_allocator : public __gnu_cxx::Allocator<_Tp, 
__gnu_cxx::__sgi_alloc>
    {/*possibly empty*/};

These alternatives would be defined in another namespace, and could be 
used as _Alloc template parameters.  I'm not sure if that constitutes 
support, but the approach is technically feasible.  It's also quite 
radical, which is why I placed it "in the long run," but the payoff is 
substantial.  In this approach, a lot of allocator complexity is 
implemented by ordinary classes instead of template classes, thereby 
simplifying maintenance and facilitating custom/future allocator 
development.  In fact, these classes can just wrap calls to a pair of 
functions defined in some namespace.

 >  The hope is that the default allocator will just be known as 
std::allocator.
 >  End of confusion, period.

If you buy the idea of separating an allocator's implementation into 
the standard stuff and an underlying GSA, while offering a variety of 
these GSA's and a way of composing standard allocators from them, then 
one of these GSA's must be the default.

 >  Then, the ext allocators will actually be named something that makes
 >  sense via inspection. Of __mt_alloc and __pool_alloc, __pool_alloc is
 >  a bit better in this regard.

Default Allocator may be just as bad; they're all redundant in some way.

The question is whether users care more about how these things work, or 
what they are.  Many allocators use some sort of pooling technique, and 
many are designed to support multithreaded applications, so focusing on 
these aspects can lead to naming conflicts.  On the other hand, SGI 
Allocator refers to the allocator's legacy status, thereby hinting that 
it's probably not the one people will want to use.  __pg_alloc (Pretty 
Good Allocator) is cute.  Maybe __so_alloc (Small Object Allocator) ...


Felix