Re: [boost] implementation of moveconstructor (was [shared_ptr]dangerous implementation of moveconstructor)

From: Martin Bonner (Martin.Bonner_at_[hidden])
Date: 2007-04-17 12:48:42

>From Sohail Somani:
>> [mailto:boost-bounces_at_[hidden]] 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: [phone] / 203894 (direct)
Fax: [phone]
Email: martin.bonner_at_[hidden]
www.pi-shurlok.com