Implementing clean and simple move symantics

[Chris Jefferson]

Joe Buck wrote:

>On Tue, Nov 23, 2004 at 05:55:36PM +0000, Chris Jefferson wrote:
>  
>
>>[ approach to move semantics ]
>>
>>For most types T , using this involves 2 steps:
>>1) Add an overload to _Moveable while sets _M_type to 1.
>>2) Add a new constructor which takes _Moveable<T> t, performs default 
>>construction then does this->swap(t)
>>3) Add a new operator= which takes _Moveable<T> t and performs 
>>this->swap(t);
>>    
>>
>
>This will yield improvements for types where default construction is
>cheap, and swapping is cheap.  But it is inferior to what could be
>achieved if you take advantage of objects that can be relocated by a
>simple memmove.  Consider std::vector<std::string>, where an element in
>the middle of the vector is erased.  Ideally, we would want to destroy the
>deleted element, then use memmove to shift the whole array of strings back
>by one (no need to adjust any reference counts).  With your approach, it
>appears that we must do N swaps (where N is the number of elements
>following the deleted element), followed by the destruction of the element
>to be deleted).  It appears that at least three times as many word read
>and word write operations are needed (the swap does three assignments
>where the memmove needs one).  If you're going to do the work of modifying
>everything, you may as well have a vector class that is three times
>faster.
>
>Nevertheless, swap is better if you really need a swap, as you do in
>sorting.  I think that the move semantics work should support both
>methods.  
>  
>
Hmm.. I'll have to think about this a bit. In actual fact, I think all 
of the standard containers look like they can be moved by memmove, and 
(quick test program), that is faster even for things like sorting 
vectors of vectors and such things. However using memmove involves being 
quite careful if its being used for things like sorting, and I suspect 
it would be very hard to avoid code duplication (which is what I was 
trying to do before). It might simply be unavoidable, in which case 
we'll have to live with it :)

Chris