Rule-of-Three becomes Rule-of-Five with C++11?

Question

So, after watching this wonderful lecture on rvalue references, I thought that every class would benefit of such a "move constructor", template<class T> MyClass(T&& other) edit and of course a "move assignment operator", template<class T> MyClass& operator=(T&& other) as Philipp points out in his answer, if it has dynamically allocated members, or generally stores pointers. Just like you should have a copy-ctor, assignment operator and destructor if the points mentioned before apply. Thoughts?

Answer 1

I'd say the Rule of Three becomes the Rule of Three, Four and Five:

Each class should explicitly define exactly one of the following set of special member functions:

• None
• Destructor, copy constructor, copy assignment operator

In addition, each class that explicitly defines a destructor may explicitly define a move constructor and/or a move assignment operator.

Usually, one of the following sets of special member functions is sensible:

• None (for many simple classes where the implicitly generated special member functions are correct and fast)
• Destructor, copy constructor, copy assignment operator (in this case the class will not be movable)
• Destructor, move constructor, move assignment operator (in this case the class will not be copyable, useful for resource-managing classes where the underlying resource is not copyable)
• Destructor, copy constructor, copy assignment operator, move constructor (because of copy elision, there is no overhead if the copy assignment operator takes its argument by value)
• Destructor, copy constructor, copy assignment operator, move constructor, move assignment operator

Note:

• That move constructor and move assignment operator won't be generated for a class that explicitly declares any of the other special member functions (like destructor or copy-constructor or move-assignment operator).
• That copy constructor and copy assignment operator won't be generated for a class that explicitly declares a move constructor or move assignment operator.
• And that a class with an explicitly declared destructor and implicitly defined copy constructor or implicitly defined copy assignment operator is considered deprecated.

In particular, the following perfectly valid C++03 polymorphic base class:

class C {   virtual ~C() { }   // allow subtype polymorphism }; 

Should be rewritten as follows:

class C {   C(const C&) = default;               // Copy constructor   C(C&&) = default;                    // Move constructor   C& operator=(const C&) = default;  // Copy assignment operator   C& operator=(C&&) = default;       // Move assignment operator   virtual ~C() { }                     // Destructor }; 

A bit annoying, but probably better than the alternative (in this case, automatic generation of special member functions for copying only, without move possibility).

In contrast to the Rule of the Big Three, where failing to adhere to the rule can cause serious damage, not explicitly declaring the move constructor and move assignment operator is generally fine but often suboptimal with respect to efficiency. As mentioned above, move constructor and move assignment operators are only generated if there is no explicitly declared copy constructor, copy assignment operator or destructor. This is not symmetric to the traditional C++03 behavior with respect to auto-generation of copy constructor and copy assignment operator, but is much safer. So the possibility to define move constructors and move assignment operators is very useful and creates new possibilities (purely movable classes), but classes that adhere to the C++03 Rule of the Big Three will still be fine.

For resource-managing classes you can define the copy constructor and copy assignment operator as deleted (which counts as definition) if the underlying resource cannot be copied. Often you still want move constructor and move assignment operator. Copy and move assignment operators will often be implemented using swap, as in C++03. Talking about swap; if we already have a move-constructor and move-assignment operator, specializing std::swap will become unimportant, because the generic std::swap uses the move-constructor and move-assignment operator if available (and that should be fast enough).

Classes that are not meant for resource management (i.e., no non-empty destructor) or subtype polymorphism (i.e., no virtual destructor) should declare none of the five special member functions; they will all be auto-generated and behave correct and fast.

Answer 2

I can't believe that nobody linked to this.

Basically article argues for "Rule of Zero". It is not appropriate for me to quote entire article but I believe this is the main point:

Classes that have custom destructors, copy/move constructors or copy/move assignment operators should deal exclusively with ownership. Other classes should not have custom destructors, copy/move constructors or copy/move assignment operators.

Also this bit is IMHO important:

Common "ownership-in-a-package" classes are included in the standard library: std::unique_ptr and std::shared_ptr. Through the use of custom deleter objects, both have been made flexible enough to manage virtually any kind of resource.