C++11 move constructor not called, default constructor preferred

Question

Suppose we have this class:

class X {
public:
    explicit X (char* c) { cout<<"ctor"<<endl; init(c); };
    X (X& lv)  { cout<<"copy"<<endl;  init(lv.c_); };
    X (X&& rv) { cout<<"move"<<endl;  c_ = rv.c_; rv.c_ = nullptr; };

    const char* c() { return c_; };

private:
    void init(char *c) { c_ = new char[strlen(c)+1]; strcpy(c_, c); };
    char* c_;

};

and this sample usage:

X x("test");
cout << x.c() << endl;
X y(x);
cout << y.c() << endl;
X z( X("test") );
cout << z.c() << endl;

The output is:

ctor
test
copy
test
ctor   <-- why not move?
test

I am using VS2010 with default settings. I'd expect the last object (z) to be move-constructed, but it's not! If I use X z( move(X("test")) ); then the last lines of the output are ctor move test, as I'd expect. Is it a case of (N)RVO?

Q: Should the move-ctor be called according to the standard? If so, why isn't it called?

Answer 1

I'd just like to add a bit of background, why this question probably gets asked "so frequently": there exists a video on youtube made by Bjarne Stroustrup (9 years ago already), where he goes about the move semantics for quite some time. what many people seem to have missed, is, that he tries to emphasize that this is a feature of c++11, and older compilers could sometimes do "that trickory by themselves". But he also mentions (very briefly) at the end of that section, that in newer versions "this copy can be optimized away". along with the problem of not seeing the laser pointer and the powerpoint at the same time, the whole video is rather confusing...

Anyways, here is the summary:

1. c++ before version 11: SOME compilers could do that stuff
2. c++ at version 11: moving is now part of the open standard
3. c++ after version 11: most move ctor's are being "optimized away".

Also Update as for Visual Studio 2022: In VS2022, you need to add the VS2015 "toolset" in order to be able to compile with c++11 standard. it's just the whole "workload" for c++ desktop development PLUS a little (rather nasty) box to check called "MSVC v140 - VS 2015 C++ Buildtools..."

you can then set the buildtools in the project settings of the particular vs project / solution from 2022 to 2015 - and enjoy your matrices being finally moved instead of not being moved (because it'd be optimized away in c++14 and further 8)...)

Answer 2

Just wanted to comment that if you only want to make sure the move ctor works, you can hack the code to eliminate the compiler optimization by throwing in a condition, for example:

X z( some_val > 1 ? X("test") : X("other test"));

Answer 3

The ctor output you get in your third code line is for the construction of the temporary object. After that, indeed, the temporary is moved into the new variable z. In such a situation the compiler may choose to elide the copy/move, and it seems that is what it did.

The Standard states:

(§12.8/31) When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object, even if the copy/move constructor and/or destructor for the object have side effects. [...] This elision of copy/move operations, called copy elision, is permitted in the following circumstances (which may be combined to eliminate multiple copies):
[...]
- when a temporary class object that has not been bound to a reference (12.2) would be copied/moved to a class object with the same cv-unqualified type, the copy/move operation can be omitted by constructing the temporary object directly into the target of the omitted copy/move
[...]

One important condition is that the source object and the destination are of the same type (apart from cv-qualification, i.e. things like const).

Therefore, one way you can force the move constructor to be called is to combine the object initialization with implicit type conversion:

#include <iostream>

struct B
{};

struct A
{
  A() {}
  A(A&& a) {
    std::cout << "move" << std::endl;
  }
  A(B&& b) {
    std::cout << "move from B" << std::endl;
  }
};


int main()
{
  A a1 = A(); // move elided
  A a2 = B(); // move not elided because of type conversion
  return 0;
}

Answer 4

What you are seeing is copy elision, which allows the compiler to directly construct a temporary into a target it is to be copied/moved into and thus elide a copy (or move) constructor/destructor pair. The situations in which the compiler is allowed to apply copy elision are specified in §12.8.32 of the C++11 standard:

When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object, even if the copy/move constructor and/or destructor for the object have side effects. In such cases, the implementation treats the source and target of the omitted copy/move operation as simply two different ways of referring to the same object, and the destruction of that object occurs at the later of the times when the two objects would have been destroyed without the optimization. This elision of copy/move operations, called copy elision, is permitted in the following circumstances (which maybe combined to eliminate multiple copies):

• in a return statement in a function with a class return type, when the expression is the name of a non-volatile automatic object with
  the same cv-unqualified type as the function return type, the
  copy/move operation can be omitted by constructing the automatic
  object directly into the function’s return value
• in a throw-expression, when the operand is the name of a non-volatile automatic object whose scope does not extend beyond the end of the innermost enclosing try-block (if there is one), the copy/move operation from the operand to the exception object (15.1) can be omitted by constructing the automatic object directly into the exception object
• when a temporary class object that has not been bound to a reference (12.2) would be copied/moved to a class object with he same cv-unqualified type, the copy/move operation can be omitted by constructing the temporary object directly into the target of the
  omitted copy/move
• when the exception-declaration of an exception handler (Clause 15) declares an object of the same type (except for cv-qualification) as
  the exception object (15.1), the copy/move operation can be omitted
  bytreatingthe exception-declaration as an alias for the exception
  object if the meaning of the program will be unchanged except for the execution of constructors and destructors for the object declared by
  the exception-declaration.

Answer 5

You are calling X's char* constructor X("test") explicitly.

Therefore it is printing ctor