Re: [v3] allocator switches

[Felix Yen <fwy at alumni dot brown dot edu>]

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

Very nice.

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

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


Felix