From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-02-05 13:26:04
From: "Howard Hinnant" <hinnant_at_[hidden]>
> Otoh, I can imagine that it might be inconvenient for vector to use #3
> instead of #1 followed, but not immediately followed, by a destructor
> call (again for exception safety reasons). You might choose to build
> the new buffer up, leaving the old buffer in a constructed valid state
> until all of the x have been successfully copy constructed in. And only
> then destruct the elements in the original buffer and swap the buffers.
> So in this latter implementation, (as far as vector is concerned) a
> class that doesn't support 1 and 2 is not movable.
But isn't this inefficient? One of our goals is to eliminate copy
constructors where possible, because they may do a deep-copy. The fast
reallocation is either move-construct-from-object + destruct or
The "insert range in the middle" operation is problematic with #3, I admit.
You could probably ensure capacity() for one extra element, copy construct
at the end, then move around using that uninitialized slot as a temporary.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk