Re: [v3] allocator switches

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

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

Names are important, but you might be a freak anyway :-)  All the 
allocators should use the same prefix convention, and I think putting 
these things in the __gnu_cxx namespace justifies removing the leading 
underscores.  pool_alloc doesn't bother me, partly because that name 
(ignoring underscores) has been exposed for a while via the online 
documentation.  I prefer sgi_alloc though, or deprecated_alloc :-)

Re: refactoring proposal.  It is strange, given that you've just killed 
the SGI-style interface.  On the other hand, the layered design is 
supposed to introduce clarity by encapsulating the code that's common 
to all standard allocators.  When that code is cloned, you have to 
examine several allocators to discover where this boundary is.  
Unfortunately, my example was bogus, because it neglected to illustrate 
all the stuff that can't be handled by a base class.  The allocator 
must provide direct support for rebinding and define the usual 
assortment of constructors.  And then there are those pesky global 
comparison operators.

I think the SGI-style interface's biggest problem is its similarity 
with the standard.  Buried in it is one good idea: allocation is 
inherently byte-oriented, not object-oriented.  GSA's preserve that 
idea while removing all the extraneous stuff.  Their adoption could be 
backward-compatible, though preserving the current file packaging might 
require some effort.

Less radically, the alternate allocators could inherit the common stuff 
from std::allocator, and then override allocate() and deallocate(), 
define constructors, etc.  That's how my recycling allocator handles 
standard conformance, but it may present its own file packaging 
problems.


Felix