Re: [boost] Addressing the variant issue

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-08-10 22:41:43

On Saturday 10 August 2002 10:02 am, David Abrahams wrote:
> IIUC, Howard's idea of move semantics either constructs or assigns a T,
> leaving a valid but possibly changed T behind in the source object. POD
> types, for example, are trivially-movable.

Yes, I think this is exactly what we need. I don't know the semantics Howard 
attributes to the move operation, but I could see something like:

  T* move(void* dest, T& source) throw();

Where 'dest' refers to allocated memory with suitable alignment for a T. The 
value in source is 'moved' into a new T at *dest, and the move operation 
returns static_cast<T*>(dest) (i.e., a pointer to the T that was created by 
the move operation). As you say, 'source' is still a valid T (perhaps the 
only allowable operation on 'source' is destruction?). 

That would work wonderfully :)

> Maybe we just need to ask people to give us types which are
> nothrow-movable, and to specialize some template for types they want to put
> in a variant which aren't known to be nothrow-movable.

Yep, we could do that.

> As a convenience, we could also allow people to pass trivially_movable<U>
> to the variant, which would say "I know memcpy moves this type, and I don't
> feel like specializing".

Maybe 'location_independent<U>' ? I'm trying to get down to the core idea 
behind trivially moveable, which---I think---is that you can memcpy the bits 
to a completely different location without changing the object. (This doesn't 
jive well with the 'move' semantics above, because the source wouldn't 
necessarily be safe to destruct).

        Doug