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