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

[Benjamin Kosnik <bkoz at redhat dot com>]

> in Oxford the removal of those allocator members has been decided. 

Also the member function address...

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

Yes.

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

do you mean allocate/deallocate here?

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

Not that I can see. You're still keeping the C++98 interface.

At the very least, I think this is worth having a patch for, just so 
that somebody can indicate that this has been implemented and the issues 
were not severe.

best,
-benjamin