[RFC] Removal of allocator::construct / destroy vs our containers

Howard Hinnant hhinnant@apple.com
Fri Apr 27 00:23:00 GMT 2007

On Apr 26, 2007, at 6:28 PM, Paolo Carlini wrote:

> Hi,
> in Oxford the removal of those allocator members has been decided.  
> Immediately, people figured out that, for compatibility with  
> existin user code a good path would be not actually removing the  
> members from the  delivered allocators, but stop as soon as  
> possible calling those member functions from the containers (in  
> fact, the *current* standard, nowhere mandates that those members  
> must be called): certainly, in the case of v3, that would mean a  
> nice semplification of stl_construct.h, stl_uninitialized.h and  
> many container headers. It would also mean, unless i'm badly  
> confused, not risking at all passing around by value allocators  
> only because allocator::construct and destroy are non-constant  
> members.
> Can you imagine problems with such a plan? Do we have principled  
> reasons to delay it to when a full C++0x implementation of the  
> library will be delivered?

This sounds like the beginnings of a good plan.  I just wanted to add  
one note of caution:  The LWG subgroup decided to eliminate these  
members of allocator.  However the full committee slapped us down and  
said we were moving too fast (and with good reason).  So it isn't a  
done deal yet.  We may well do this in Jul. or Oct.  But we haven't  
done it yet, and I've seen committees turn on a dime.  I think having  
a plan in place is a very good idea.  But we might not want to  
execute the plan yet.


More information about the Libstdc++ mailing list