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

From: Sohail Somani (s.somani_at_[hidden])
Date: 2007-04-17 12:36:31

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

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.

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

Sohail