When are implicit move constructors not good enough?

Question

When are implicit move constructors not good enough?

Should I treat it like destructors and copy constructors, where it's generally only necessary if I manage my own memory?

Is the implicit move constructor good enough in this (very contrived) scenario:

class A { private:     B b;     std::string name;  public:     A();     std::string getName() const {         return name;     }      B getB() const {         return b;     } };  class B { private:     std::vector list;  public:      B();     std::vector getList() const {         return list;     } }; 

Answer 1

The answer here is based on result of Google search.

Quoting from Andrzej's C++ blog

> When should I define move constructor for my class?

It greatly depends on what your class does and how it is implemented. First, for ‘aggregate’ classes, which only group other data for convenience/clarity, move constructors will be implicitly generated by the compiler. Consider the following class.

struct Country {   std::string name;   std::vector<std::string>  cities; }; 

In a typical C++ struct many special member functions — like copy constructor, copy assignment, destructor — are auto-generated. This also includes move constructor (and move assignment).

For more sophisticated classes, which encapsulate their implementation details, the answer is more interesting. One of the main goals of move semantics (move constructor, move assignment) is to give the compiler two tools for implementing value semantics (passing arguments by value, returning by value) for user defined types:

1. Making two identical objects out of one — it needs to be expensive.
2. Moving one object from one memory location to the other — it can be made very fast.

If for your class it is possible to implement move constructor that would be faster than the copy constructor, you should implement it for run-time speed optimization purposes. We have seen how it can be implemented for vector in this link. However, it is not for all types that such move constructor, faster than a copy constructor, can be implemented. Consider the following matrix representation.

class Matrix {   std::complex<long double> data[1000][1000]; }; 

Because all memory required for matrix representation is declared in class scope (unlike in vector, which uses heap-allocated memory) there is no way to apply only a small number of assignments. We will need to do a copying for each array element. There is no point in defining move constructor, as it will be no faster than copying.

Another valid reason for providing your move constructor if you want to enable your type that is non-copyable (because it is RAII-like and represents a resource) to be still passed by value where copying is not required, and stored in STL containers. Such unique ownership semantics are explained in more detail in this link.