Re: [v3] allocator switches

[Benjamin Kosnik <bkoz at redhat dot com>]

>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.

I see what you are suggesting now, thanks for the details.

Although I think this would probably work, I'm uncertain if the effort
is worth the payoff: we do some template gymnastics to make it possible
for people to write non-templatized allocators that just have
allocate/delete members.

Hmmmm.

Versus the other option, which to to just adopt the C++ standard
interface to allocators, and use them. As is. Sure, other interfaces
could be devised, but hey. The one that is in the standard isn't so
horrible.

The whole point of this exercise is to move to a way of using allocators
that people understand or can be explained from third-party books
explaining the standard C++ library, and is portable between different
C++ implementations. Remove the tricks, and hope that the clarity makes
it easier for people to use custom allocators.

>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) ...

I suppose you are right. I was hoping that we can pick descriptive names
based on how the allocators work, and that these names will be both
descriptive, and unique.  

This may be impossible, in which case things like __sgi_alloc,
__so_alloc (Stefan O's), etc are viable instead.

I suppose it doesn't really matter, and I'm just being a freak.

-benjamin