Re: [boost] [proposal] raw move (was: [interest] underlying type library)

Subject: Re: [boost] [proposal] raw move (was: [interest] underlying type library)
From: Nevin Liber (nevin_at_[hidden])
Date: 2011-08-23 15:47:30

On 23 August 2011 13:13, Julian Gonggrijp <j.gonggrijp_at_[hidden]> wrote:
> Nevin Liber wrote:
>
>> In the C++11 move case, the moved-from object itself doesn't know if it is
>> about to be destroyed or reused, so it has to be put in a state where either
>> can happen.
>
> Excuse me, but that doesn't seem logical. You are saying that since
> the object doesn't know what is going to happen, the programmer has to
> prepare it for both scenarios.

C++11 move semantics have a requirement that the source object is left
in a valid but unspecified state.

Given that T is a MoveConstructible and MoveAssignable type:

T a(T_Factory());
T b(T_Factory());

// ...

a = std::move(b);

1.  At this point, what operations can you perform on a?
2.  At this point, what operations can you perform on b?

a still has to be destructible and assignable, as a cannot possibly
know how it is going to be used past this point.  Any other operations
on a would have to be documented (for instance, there are stronger
requirements on move semantics for standard library types).

b has no restrictions on the operations that can be called.

My question is, given:

T c(T_Factory());
T d(T_Factory());

// ...
move_raw(c, d);

3.  At this point, what operations can you perform on c?
4.  At this point, what operations can you perform on d?
-- 
 Nevin ":-)" Liber  <mailto:nevin_at_[hidden]>  [phone]