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

[Benjamin Kosnik]

Paolo Carlini wrote:
> 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?

I think we should go ahead with this transformation. It is conforming to 
C++98 as well as forward-looking to C++0x: seems like an obvious win.

I've cc'd Matt on this in the hopes that he'll take a gander at this. It 
certainly seems to me that this is exactly what he intended.

As part of this, I noticed that there are no construct or destroy 
exports from the libstdc++ shared library, because 1) these functions 
are inline and small, 2) mostly unused. So, strictly binary-wise, this 
change doesn't break the ABI. It is a change to the API however, and a 
removal of public member functions so we cannot go through and kill 
these members in the ext/*_allocator.h files.

It would probably be worth going through those files and adding in

  // XXX GLIBCXX_ABI Deprecated

markers next to these member functions, to make it more obvious as to 
our intentions with the next ABI break.

-benjamin