19

12.8 Copying and moving class objects [class.copy] §31 and §32 say:

in a return statement in a function with a class return type, 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, the copy/move operation can be omitted by constructing the automatic object directly into the function’s return value

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.

Hence we can write:

unique_ptr<int> make_answer()
{
    unique_ptr<int> result(new int(42));
    return result;   // lvalue is implicitly treated as rvalue
}

However, I noticed that g++ 4.6.3 also accepts lvalues that are not names, for example:

    return (result);
    return *&result;
    return true ? result : result;

By contrast, return rand() ? result : result; does not work. Is the compiler's optimizer interfering with the language semantics? As I interpret the standard, return (result); should not compile, because (result) is not a name, but a parenthesized expression. Am I right or wrong?

Community
  • 1
  • 1
fredoverflow
  • 256,549
  • 94
  • 388
  • 662
  • Removed the [tag:ownership] tag, since that only applies to the specific example and that can easily be changed to something not involving ownership., – Xeo Jul 16 '12 at 17:58
  • The quote would better have its contextual part intact, starting from "This elision of copy/move operations, called copy elision, is permitted in the following circumstances (which may be combined to eliminate multiple copies):" or from an earlier point in the paragraph. – Desmond Hume Jul 16 '12 at 18:02
  • 2
    I can now confirm that VS2010 exhibits the same behaviour, generating a call to the move constructor for the first two cases, but complains about an inaccessible copy ctor for the third. Interestingly, Intellisense already complains in the second case that the copy ctor should be called and is inaccessible. FWIW, GCC 4.7.1 passes on all 3. – Xeo Jul 16 '12 at 18:05
  • 1
    [The conditional for return value normally defeats NRVO.](http://en.wikipedia.org/wiki/NRVO#Compiler_support) – Maxim Egorushkin Jul 16 '12 at 18:06

2 Answers2

10

Regarding parenthesized expressions [√]

You are wrong when talking about parenthesized expressions and that it shouldn't be able to trigger a move when being returned and containing only the name of a moveable object.

5.1.1/1      General      [expr.prim.general]

A parenthesized expression is a primary expression whose type and value are identical to those of the enclosed expression. The presence of parentheses does not affect whether the expression is an lvalue. The parenthesized expression can be used in exactly the same contexts as those where the enclosed expression can be used, and with the same meaning, except as otherwise indicated.


Regarding the constexpr conditional operator [╳]

The way I interpret the standard in regards to constant-expressions and he coditional operator is that the use of return true ? result : result is well-behaved since it is a constant expression and therefore equivalent to return result;

I have now gone through the standard more carefully and nowhere does it say that a constant conditional-expression is the same as if only the "returned" expression would have been written.

true ? <expr1> : <expr2>; // this is not the same as just writing <expr1>;

Regarding return *&result; [╳]

In C99 it is explicitly stated that *&result is the exact equivalent of having written result instead, this is not the case in the C++ specification.

Though we can all agree on that using *&result will indeed yield the same lvalue as result, but according to the standard *&result (of course) isn't an expression where "the expression is the name of a non-volatile automatic object".

Sure, the expression contains an appropriate name, but it's not just only that.


To sum things up...

return result; // #1, OK

return (result);                  // as described earlier, OK
return true ? result : result;    // as described earlier, ill-formed
return rand () ? result : result; // as described earlier, ill-formed
return *&result;                  // as described earlier, ill-formed
Community
  • 1
  • 1
Filip Roséen - refp
  • 62,493
  • 20
  • 150
  • 196
  • 2
    The second case should also be ill-formed, since the ternary operator is an *expression* and doesn't denote the name of an automatic object. Optimizations are not allowed to change the observable behaviour of the program (except for copy elision etc). – Xeo Jul 16 '12 at 18:21
  • 4
    I'm not so sure about that. The ternary operator is usable, for example, in `constexpr` functions, or array indices. – Puppy Jul 16 '12 at 18:46
  • 1
    @DeadMG I am. A condition being a constant expression doesn't change the source code from being a conditional operator expression to being a name. It being usable in constant expressions is irrelevant. – Johannes Schaub - litb Jul 17 '12 at 21:09
  • 1
    Regarding `*&`, you're probably thinking about C, where `&*` is explicitly defined as no-op by `§6.5.3.2/3` (C99) – Cubbi Jul 18 '12 at 02:07
  • @Cubbi ah thanks, I'm heading out to buy smokes but will update this answer when I get back. thanks! – Filip Roséen - refp Jul 18 '12 at 02:08
1

Parenthesized expressions are equivalent to their unparenthesized expressions unless otherwise noted (as done in the ADL rules, for example, or by decltype for another example). It can sometimes be tricky when and when not something is equivalent in this manner (for example, the ADL rules don't explicitly mention "unparenthesized", but they use an explicit grammar non-terminal and examples that make it clear that parens are not taken as being equivalent).

For the other questions: Yes, GCC does several optimizations on the AST directly that makes it accept various invalid programs, like the following

int a = 42;
int *p = 0 * a;
Johannes Schaub - litb
  • 496,577
  • 130
  • 894
  • 1,212
  • @ildjarn hold your breath :) it also accepts `char *x = "hello folks" + 0;`, despite the spec only allowing this special conversion only on string-literals, not on arbitrary pointer expressions evaluating to the same address of type `char const*`. – Johannes Schaub - litb Jul 17 '12 at 21:01