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

[Paolo Carlini]

Hi Benjamin,

>> in Oxford the removal of those allocator members has been decided. 
>
> Also the member function address...

Indeed, but we are not using it ;) Actually, your point makes for an 
interesting detour: shall we take the address issue seriously? I mean, 
shall we fix "somehow" the library to not use operator& and instead 
obtain "by hand" the address of the objects? That change is not 
necessary in the current standard, but I understand in the next one 
objects will be allowed to freely overload operator&. Actually the 
reason I didn't seriously propose something yet, is that, sorry for 
being explicit, boost::addressof seems so ugly, the last time I saw it, 
exploiting *2* reinterpret_cast :( Should this get front-end support?

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

No, construct and destroy. Those are not const members and that causes 
problems. One very nice reason to remove both, I hadn't seriously 
understood until a few days ago.

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

Excellent. I will prepare one.

Paolo.