From Sohail Somani:
[mailto:boost-bounces@lists.boost.org] On Behalf Of Martin Bonner
From: Sohail Somani
The rule should be simple:
After moving, the moved object (i.e., the argument to std::move) should be destructible.
Agreed so far.
I don't think being assignable makes sense because that implies that a default constructor is sensible for T.
If T supports operator =, I think it should be possible to assign TO an object of type T that has been moved from.
I don't see how this is related to a default constructor.
Well if you do this:
T a(std::move(some_other_T)); some_other_T = yet_another_T;
Even if operator= is supported, some_other_T must(?) then be in some usable (but empty) state if you expect to assign to it. Usable in strictly limited ways. I wouldn't expect to be able to call any methods on it. (Unlike Ion and Joe.)
Empty? If you can only delete it, or assign to it, then whether it is "empty" or not is somewhat meaningless.
If its possible for T to be in a usable empty state, then conceivably, a default constructor should be possible. There is probably some rule of thumb here, just not sure what it is yet.
Hmm. I sort of see what you mean. It is often reasonable that the state of a moved from object is the same as the state of a default constructed object - but not always, and if I don't have a use-case for a
Still, for generic code, I don't think you should expect to be able to reuse a moved object except for destructing it. Specific classes, maybe, but not as a general rule. Quite.
Even still, I can't think of a case off-hand where assignment requires some previous state so maybe this is a moot point. Maybe for some really crazy overloading of operator=.
Oh that's easy! For example, smart pointers: if (this->p != null) { delete this->p; } The comparison with null is undefined behaviour if the pointer has been previously deleted, and if the memory has been subsequently reallocated it can have seriously bad effects. (Note, I am **NOT** saying that will happen with a moved from object - I am just giving an example where the behaviour of the assignment operator depends upon the state of the assigned to object). -- Martin Bonner Project Leader PI SHURLOK LTD Telephone: +44 1223 441434 / 203894 (direct) Fax: +44 1223 203999 Email: martin.bonner@pi-shurlok.com www.pi-shurlok.com