Re: [boost] Addressing the variant issue

From: David Abrahams (dave_at_[hidden])
Date: 2002-08-10 22:55:46

From: "Douglas Gregor" <gregod_at_[hidden]>

> 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?).

I think that "only destructible" is a spurious and always (in my
experience) unneccessary complication. Let's just say that source is valid
and possibly modified.

> 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.

No, that's not the whole picture. Think of auto_ptr.

> (This doesn't
> jive well with the 'move' semantics above, because the source wouldn't
> necessarily be safe to destruct).

Right. That's why I'm suggesting trivially_movable means "movable with
memcpy". We could also have swap_movable, which means "movable with swap
for move assign, default-construct + swap for move construct"

-Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com