c++ - Why no default move-assignment/move-constructor?

Question

I'm a simple programmer. My class members variables most often consists of POD-types and STL-containers. Because of this I seldom have to write assignment operators or copy constructors, as these are implemented by default.

Add to this, if I use std::move on objects not movable, it utilizes the assignment-operator, meaning std::move is perfectly safe.

As I'm a simple programmer, I'd like to take advantage of the move-capabilities without adding a move constructor/assignment operator to every class I write, as the compiler could simply implemented them as "this->member1_ = std::move(other.member1_);..."

But it doesn't (at least not in Visual 2010), is there any particular reason for this?

More importantly; is there any way to get around this?

Update: If you look down at GManNickG's answer he provides a great macro for this. And if you didn't know, if you implement move-semantics you can remove the swap member function.

Answer 1

The implicit generation of move constructors and assignment operators has been contentious and there have been major revisions in recent drafts of the C++ Standard, so currently available compilers will likely behave differently with respect to implicit generation.

For more about the history of the issue, see the 2010 WG21 papers list and search for "mov"

The current specification (N3225, from November) states (N3225 12.8/8):

If the definition of a class X does not explicitly declare a move constructor, one will be implicitly declared as defaulted if and only if

• X does not have a user-declared copy constructor, and

• X does not have a user-declared copy assignment operator,

• X does not have a user-declared move assignment operator,

• X does not have a user-declared destructor, and

• the move constructor would not be implicitly defined as deleted.

There is similar language in 12.8/22 specifying when the move assignment operator is implicitly declared as defaulted. You can find the complete list of changes made to support the current specification of implicit move generation in N3203: Tightening the conditions for generating implicit moves , which was based largely on one of the resolutions proposed by Bjarne Stroustrup's paper N3201: Moving right along.