-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] 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