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

From: Sohail Somani (s.somani_at_[hidden])
Date: 2007-04-17 20:14:17

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Joe Gottman
> 
> Sohail Somani wrote:
> > 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=.
> 
>     At a bare minimum you need to be able to destruct or assign to a 
> moved object.  For example, consider the code for inserting a 
> value into 
> the middle of an vector.  If the vector doesn't need to be 
> reallocated 
> you would use the following algorithm:

Good example. I think that's the canonical use of this feature. [A
slight tangent follows] If the rule should then be:

Moved objects should be destructible and move(?) assignable.

How do you handle classes that have reference members? I was hoping that
the compilers might be able to generate default move constructors like
they are able to do for the other *structors but now I'm not sure what
will happen in the context of references. It would be killer if I could
upgrade to a C++0x compiler and all of a sudden my reallocations don't
do deep copies.

Apologies if its covered elsewhere.

Sohail