$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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