Re: [boost] move semantics

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2002-02-06 19:42:29

On Wednesday, February 6, 2002, at 03:56  PM, Sean Parent wrote:

> It was correctly pointed out, that swap can be implemented using
> constructing moves (in the same way it is done with copying, through a
> temp). But in the case of a non-POD class, I don't think this is a win
> unless you define the source from the move to have been destructed as a
> result of the move (call this relocate).
>
> The move vs. relocate semantics would be:
>
> move - moving a source A into uninitialized memory B. The result leaves 
> A in
> an indeterminate but destructible state. "Copy" construction of an 
> auto_ptr
> is an example.
>
> relocate - moving a source A into uninitialized memory B. The result 
> leaves
> A in a destructed state. Requires the source A is also managed with
> placement new and delete.

I like these definitions, except I would also like to see moving into 
initialized memory defined (e.g. auto_ptr assignment).  They make it 
easier to discuss the variations.

I'm not understanding your comments with respect to swap implemented 
with move though:

template <class T>
void
swap(T& a, T& b)
{
        T tmp(move(a));  // move construct
        a = move(b);     // move assign
        b = move(tmp);   // move assign
}

None of these was intended to be a relocation, though the last move from 
tmp certainly could be since the next (implied) statement is the 
destruction of tmp.

> The relocate construct would be useful for container optimization - 
> but I
> think the complexities of implementing it for anything that can't be 
> treated
> as a POD (just do a memcopy for the relocate) is difficult. It may be 
> worth
> having a trait though for objects that can use memcopy to relocate.

I don't think relocation will be useful for container optimization, at 
least not vector.  I went into this in some detail under the auto_vector 
subject.  I remain unconvinced (but open minded) about its usefulness in 
general.

> The first item, I think is simplest to implement using a non-throwing
> constructor (one that constructs an object upon which the only valid
> operation is destruction) and a swap.

I suspect we've got a time delay thing going on.  I just got your post, 
but it is dated hours earlier.  Have you had a chance to look at 
Hamish's proposed code, and my response to it?  Your comments on this 
would be most valued.

-Howard