Question

I have been learning about move constructors over the last day or so, trying to stick to a general rule of returning by value as most people seem to suggest, and have come across an interesting (to me) dilemma.

Assume that I have an expensive to construct/copy class ‘C’ that has correctly defined copy constructor, assignment operator, move constructor and move assignment operator.

First, this piece of code elides the copy constructor as I expected:

C make_c1() {
    return C();
}

as does this:

C make_c2() {
    C tmp;
    return tmp;
}

and so does this (whether I pass in a 1 or 2):

C make_c3(int a) {
    return a == 1 ? make_c1() : make_c2();
}

It’s when I get to this that I have an issue:

C make_c4(int a) {
    C tmp;
    return a == 1 ? make_c1() : tmp;
}

Passing in a 1 triggers RVO for the result of make_c1, but passing in a 2 triggers the copy constructor on tmp.

Amending the function to the following causes the move constructor to be triggered for tmp instead:

C make_c5(int a) {
    C tmp;
    return a == 1 ? make_c1() : std::move(tmp);
}

All great and wonderful except…

In these simple examples, RVO has been triggered pretty much as I’d hoped.

However what if my code is slightly more complex and on some compilers doesn’t evoke RVO in that last function? In that case, I’d need to wrap my call to make_c1 in std::move, which will make the code less efficient on those compilers that do evoke RVO.

So my questions are:

1. Why was the move constructor not invoked in make_c4 when I returned my local object? (It’s about to be destroyed after all).
2. In the function make_c5, should I return the results of make_c1 by value or by moving it? (To avoid different versions of the code for differing compilers/platforms).
3. Is there a better way to code the final function so that it does the right thing for a reasonable compiler implementation?

The compiler I have been playing with is GCC 4.5.3 on Cygwin.

Answer 1

The implicit move-on-return is only legal in the same contexts in which RVO is legal. And RVO is legal when the expression is the name of a non-volatile automatic object (other than a function or catch-clause parameter) with the same cv- unqualified type as the function return type ([class.copy]/p31/b1).

If you transform make_c4 to:

C make_c4(int a) {
    C tmp;
    if (a == 1)
        return make_c1();
    return tmp;
}

Then you get the expected move construction for the call to make_c4(2). Your make_c5 rewrite is not desirable for exactly the reasons you state.

Update:

I should have also included a reference to [expr.cond]/p6/b1 which explains the semantics of the conditional expression when the second expression is a prvalue and the third is an lvalue, but both have the same type:

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.

I.e. this paragraph specifies that the resultant prvalue of the conditional is copy-initialized, from the 3rd argument in your example. Copy-initialization is defined in [dcl.init]/p14. When the source of a copy-initialization is a class-type lvalue, this will invoke the type’s copy constructor. If the source is an rvalue, it will invoke the move constructor if one exists, else it will invoke the copy constructor.

The specification of the conditional expression has no allowance for an implicit move from an lvalue argument, even if the conditional expression is part of a return expression. It is possible that the language could have been crafted to allow such an implicit move, but as far as I know, it was never proposed. Furthermore the existing specification of the conditional expression is already extremely complicated, making such change to the language all the more difficult.