Re: [v3] C++11 allocator reqs for vector in debug & profile mode

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 14 November 2011 21:15, Jonathan Wakely wrote:
> On 14 November 2011 20:15, François Dumont wrote:
>> ? ?I wonder if playing with allocator propagation in such a context is
>> right. The Standard define shrink_to_fit as a member method and not as a
>> global function. People implementing an allocator might not expect
>> allocators to be copy or anything else when calling vector::shrink_to_fit
>> which can normally be implemented without it.
>
> I don't see what being a member function or global function has to do
> with anything.
>
> Allocators must be copyable, containers take a copy of an allocator,
> if copying them misbehaves then you're in big trouble, long before
> calling shrink_to_fit.
>
> Could you explain why you think the current code is a problem?
>
> My change ensures that the new storage is created with the same
> allocator, so whether propagate_on_container_swap is true or not, the
> container ends up with the same allocator it had originally (or a copy
> of it) and storage that can be freed by that allocator.

We could of course implement shrink_to_fit() from scratch, just
manually re-allocating and moving/copying elements and deallocating,
but apart from copying the allocator I think the current code is
equivalent.

The standard doesn't place any requirements or restrictions on
shrink_to_fit so I don't think anyone should have any expectations
over how it's implemented (as long as it doesn't cause undefined
behaviour by swapping non-equal, non-propagating allocators!)