Re: [v3] allocator switches

[Benjamin Kosnik <bkoz at redhat dot com>]

> >  Here's an approach to solving the default allocator dilemma. [...]
>
>Very nice.

Thanks.

> >  I don't see the final presentation of the default underlying 
>allocator
> >  as something that has to get fixed right away, however.
>
>I agree.  In the long run, I think you want to encapsulate allocator 
>logic with a two-layer design.  Roughly speaking, std::allocator does 
>three things: (1) handle allocation/deallocation requests [which may 
>entail caching], (2) delegation based on parameters such as request 
>size [enforcing the 128-byte limit] and GLIBCXX_FORCE_NEW, and (3) 
>transformation via rebinding and other miscellaneous things like 
>exporting type definitions.

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.

That's the advantage of the proposed patch... there is some duplication
(ie the address, etc bits) but the rest is clean...

>If you encapsulate the delegation and transformation logic in a 
>template, you can minimize the size of the underlying 
>allocation/deallocation object's interface.  Its allocating method 
>would accept a byte count argument and an optional hint (usually 
>ignored).  In other words, std::allocator could be implemented by a 
>specialization of a more generic template (possibly via inheritance), 
>and the underlying implementation needn't be a template specialization. 
>  This generic template would facilitate creating allocators that use 
>other /ext implementations (refactored accordingly), and eliminate 
>redundancy.
>


> >  Also, __pool_alloc. And __mt_alloc. Please, let's figure out better 
>names.
>
>The first one could be named after the source of its algorithm (SGI 
>Allocator?) and the second one has evolved to become the Default 
>Allocator.  That way, Stefan can tell people that he worked on the 
>default allocator, instead of on the underlying implementation of ...

Huh.

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

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. The problem is that if __mt_alloc gets named
something else, will __pool_alloc still make sense?

Anyway. Angles dancing, etc.

-benjamin