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

[Paolo Carlini]

Hi,

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

In practice, the below (+ removal of a few tests only exercising 
construct / destroy) passes the testsuite and appear to work well. 
Mechanical changes, as expected.

All in all, I'm starting lo like this clean-up a lot. As already 
mentioned, we also avoid passing around allocators unnecessarily.

I'm thinking, maybe the risk would not be that big: for one, nowhere the 
standard says the containers must call allocator::construct / destroy. 
Moreover, the current consensus in the LWG is that there isn't much 
point in calling them. Therefore, even if, for some reason, eventually 
they will be remain in C++0x, so what? In any case, we would mention the 
implementation change in the release notes.

What do you think?

Paolo.

/////////////////////
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch_cons_dest
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20070428/bb8761aa/attachment.ksh>