Move constructor vs Copy elision - c++

Question

Can someone please explain me one thing. From the one side the move constructor was designed to optimize the memory & processor usage by eliminating unnecessary copying an objects BUT from other side almost everywhere the move constructor is going to be used the compiler uses copy elision, disabling the usage of the move ctor? Isn't it irrational?

Answer 1

There are plenty of cases where the move constructor will still get called and copy elision is not being used:
// inserting existing objects into a container
MyObject myobject;
std::vector<MyObject> myvector;
myvector.push_back(std::move(myobject));
// inserting temporary objects into a container
myvector.push_back(MyObject());
// swapping
MyObject other;
std::swap(myobject, other);
// calling functions with existing objects
void foo(MyObject x);
foo(std::move(myobject));
... and many more.
The only instance where there is mandatory copy elision (since C++17) is when constructing values from the result of a function call or a constructor. In such cases, the compiler isn't even allowed to use the move constructor. For example:
MyObject bar() {
return MyObject();
}
void example() {
MyObject x = bar(); // copy elision here
MyObject y = MyObject(); // also here
}
In general, the purpose of copy elision is not to eliminate move construction alltogether, but to avoid unnecessary constructions when initializing variables from prvalues.
See cppreference on Copy Elision.

Answer 2

Here is a simple example where move is called. It is a toy example for which the rule of zero could have been relevant, but assume that there are also other members inside the class that require going with the rule of five.
class A {
std::string s;
public:
A(const char* s = ""): s(s) {}
~A() {}
A(const A& a): s(a.s) {
std::cout << "copy ctor" << std::endl;
}
A& operator=(const A& a) {
s = a.s;
std::cout << "copy assignment" << std::endl;
return *this;
}
A(A&& a): s(std::move(a.s)) {
std::cout << "move ctor" << std::endl;
}
A& operator=(A&& a) {
s = std::move(a.s);
std::cout << "move assignment" << std::endl;
return *this;
}
};
int main() {
A a;
a = "hi"; // move
// suppose we KNOW here that a is not needed anymore
A a2 = std::move(a); // move
a = "bye"; // move
}
Code: http://coliru.stacked-crooked.com/a/97d25c43e0edb00b

Answer 3

Because copy elision has limits, compiler must know the lifetime of an object to predict whether copy elision can be done.
For example:
std::vecter<MyObj> v;
v.push(MyObj()); // compiler has a higher chance to do the copy elision
but consider this:
MyObj my_obj;
v.push(my_obj)
// ...
// my_obj will never use
in this case, the compiler won't know that the my_obj will be never use, so the normal copy will performed. If efficiency matters, you have to use v.push(std::move(my_obj)); to explicit tell the compiler that "I will never use my_obj again"

Answer 4

move constructor was designed to optimize the memory & processor usage by eliminating unnecessary copying an object
That is not true. A move construction creates a new object to which the data of the old object is "moved" (in the worst case if all data of the source object is fully enclosed in it, it is as expensive as a regular copy) a move constructor has only benefited over a copy constructor if you have member variables that can be swapped like pointers or containers that support swapping (or if it holds resources that can't be copied)
So copy elision is always desired over a move ctor. But that does not mean that a move ctor does not have any use. In many cases, however, a move ctor is just syntactic sugar over swap and reset/empty/destruct (not exactly true, but closely).
Besides the swap case, a move ctor is also useful for things that are or should not be copyable and for which you don't want to use pointers. e.g. a std::uniqu_ptr should not be copyable because of the unique ownership, but you might want to pass the ownership while calling a function, so moving its resources is important.
You can see move sematic as a standardized process, so that copy elision if possible, and if it is not a fallback to move ctor.