Compiler's choice between move and copy constructor

Question

Minimal example:

#include <iostream>

struct my_class
{
    int i;
    my_class() : i(0) { std::cout << "default" << std::endl; }
    my_class(const my_class&) { std::cout << "copy" << std::endl; }
    my_class(my_class&& other) { std::cout << "move" << std::endl; }
    my_class(const my_class&& other) { std::cout << "move" << std::endl; }
};

my_class get(int c)
{
    my_class m1;
    my_class m2;
    return (c == 1) ? m1 : m2; // A
    //return (c == 1) ? std::move(m1) : m2; // B
    //return (c == 1) ? m1 : std::move(m2); // C
}

int main()
{
    bool c;
    std::cin >> c;
    my_class m = get(c);
    std::cout << m.i << std::endl; // nvm about undefinedness
    return 0;
}

Compiled:

g++ -std=c++11 -Wall -O3 ctor.cpp -o ctor # g++ v 4.7.1

Input:

1

Output:

default
default
copy
-1220217339

This is the In/Output with line A or line C. If I use line B, instead, I get std::move for some strange reason. In all versions, the output does not depend on my input (except for the value of i).

My questions:

• Why do versions B and C differ?
• Why, at all, does the compiler make a copy in cases A and C?

Answer 1

Where is the surprise...? You are returning local objects but you are not directly returning them. If you'd return a local variable directly, you'll get move construction:

my_class f() {
    my_class variable;
    return variable;
}

The relevant clause is, I think, 12.8 [class.copy] paragraph 32:

When the criteria for elision of a copy operation are met or would be met save for the fact that the source object is a function parameter, and the object to be copied is designated by an lvalue, overload resolution to select the constructor for the copy is first performed as if the object were designated by an rvalue. [...]

However, choosing a named object to be selected from a conditional operator isn't eligible for copy elision: the compiler can't know until after the objects are constructed which of the objects to return and copy elision is based on constructing the object readily in the location where it needs to go.

When you have a condition operator, there are two fundamental situations:

1. Both branches produce exactly the same type and the result will be a reference to the result.
2. The branches differ somehow and the result will be a temporary constructed from the selected branch.

That is, when returning c == 1? m1: m2 you get a my_class& which is an lvalue and it is, thus, copied to produce the return value. You probably want to use std::move(c == 1? m1: m2) to move the selected local variable.

When you use c == 1? std::move(m1): m2 or c == 1? m1: std::move(m2) the types differ and you get the result of

return c == 1? my_class(std::move(m1)): my_class(m2);

or

return c == 1? my_class(m1): my_class(std::move(m2));

That is, depending on how the expression is formulated the temporary is copy constructed in one branch and move constructed on the other branch. Which branch is chosen depends entirely on the value of c. In both cases the result of the conditional expression is eligible for copy elision and the copy/move used to construct the actual result is likely to be elided.

Answer 2

Conditional operator effect!

You're returning through a conditional operator

return (c == 1) ? m1 : m2;

The second and third operands have the same type; the result is of that type. If the operands have class type, the result is a prvalue temporary of the result type, which is copy-initialized from either the second operand or the third operand depending on the value of the first operand. [§ 5.16/6]

Then you have a copy. This code has the your expected result.

if (c==1)
   return m1;
else
   return m2;

Answer 3

1. If my_class is as expensive to copy as copying an int, the compiler isn't motivated to eliminate the copies, in fact, it is motivated to do copies. Don't forget that your get(int c) function can be completely inlined! It can lead to a very confusing output. You need to motivate the compiler to do its best to eliminate the copies by adding a big, heavy payload to your class that is expensive to copy.

2. Furthermore, instead of relying on undefined behavior, try to write code that tells you in a well-defined manner whether a move or a copy occurred or not.

3. There are 2 more interesting cases: (i) when you apply move on both arguments of the ternary conditional operator and (ii) when you return through if-else instead of the conditional operator.

---

I rearranged your code: I gave my_class a heavy payload that is really expensive to copy; I added a member function that tells you in a well-defined manner if the class has been copied or not; I added the 2 other interesting cases.

#include <iostream>
#include <string>
#include <vector>

class weight {
public:  
    weight() : v(1024, 0) { };
    weight(const weight& ) : v(1024, 1) { }
    weight(weight&& other) { v.swap(other.v); }
    weight& operator=(const weight& ) = delete;
    weight& operator=(weight&& ) = delete;
    bool has_been_copied() const { return v.at(0); }
private:
    std::vector<int> v;
};

struct my_class {
    weight w;
};

my_class A(int c) {
    std::cout << __PRETTY_FUNCTION__ << std::endl;
    my_class m1;
    my_class m2;
    return (c == 1) ? m1 : m2;
}

my_class B(int c) {
    std::cout << __PRETTY_FUNCTION__ << std::endl;
    my_class m1;
    my_class m2;
    return (c == 1) ? std::move(m1) : m2;
}

my_class C(int c) {
    std::cout << __PRETTY_FUNCTION__ << std::endl;
    my_class m1;
    my_class m2;
    return (c == 1) ? m1 : std::move(m2);
}

my_class D(int c) {
    std::cout << __PRETTY_FUNCTION__ << std::endl;
    my_class m1;
    my_class m2;
    return (c == 1) ? std::move(m1) : std::move(m2);
}

my_class E(int c) {
    std::cout << __PRETTY_FUNCTION__ << std::endl;
    my_class m1;
    my_class m2;
    if (c==1) 
      return m1;
    else
      return m2;
}

int main(int argc, char* argv[]) {

    if (argc==1) {
      return 1; 
    }

    int i = std::stoi(argv[1]);

    my_class a = A(i);
    std::cout << a.w.has_been_copied() << std::endl;

    my_class b = B(i);
    std::cout << b.w.has_been_copied() << std::endl;

    my_class c = C(i);
    std::cout << c.w.has_been_copied() << std::endl;

    my_class d = D(i);
    std::cout << d.w.has_been_copied() << std::endl;

    my_class e = E(i);
    std::cout << e.w.has_been_copied() << std::endl;
}

Output with ./a.out 0

my_class A(int)
1
my_class B(int)
1
my_class C(int)
0
my_class D(int)
0
my_class E(int)
0

Output with ./a.out 1

my_class A(int)
1
my_class B(int)
0
my_class C(int)
1
my_class D(int)
0
my_class E(int)
0

---

As to what happens and why, others have already answered it as I was writing up this answer. If you go through the conditional operator, you lose the eligibility to copy elision. You can still get away with a move construction if you apply move. If you look at the output, that's exactly what happens. I have tested it with both clang 3.4 trunk and gcc 4.7.2 at optimization level -O3; the same output is obtained.

Answer 4

the compiler doesn't HAVE to move, the point of move is to be a lot faster than a copy and destruct. BUT the two yield the same result.