13

Why does the ternary operator prevent Return-Value Optimization (RVO) in MSVC? Consider the following complete example program:

#include <iostream>

struct Example
{
    Example(int) {}
    Example(Example const &) { std::cout << "copy\n"; }
};

Example FunctionUsingIf(int i)
{
    if (i == 1)
        return Example(1);
    else
        return Example(2);
}

Example FunctionUsingTernaryOperator(int i)
{
    return (i == 1) ? Example(1) : Example(2);
}

int main()
{
    std::cout << "using if:\n";
    Example obj1 = FunctionUsingIf(0);
    std::cout << "using ternary operator:\n";
    Example obj2 = FunctionUsingTernaryOperator(0);
}

Compiled like this with VC 2013: cl /nologo /EHsc /Za /W4 /O2 stackoverflow.cpp

Output:

using if:
using ternary operator:
copy

So apparently the ternary operator somehow prevents RVO. Why? Why would the compiler not be clever enough to see that the function using the ternary operator does the same thing as the one using the if statement, and optimize accordingly?

Christian Hackl
  • 27,051
  • 3
  • 32
  • 62
  • 2
    Could be a compiler thing. Gcc doesn't cause a copy: http://coliru.stacked-crooked.com/a/ab6969a2cb4b499a – tmaric Feb 27 '14 at 19:09
  • @tomislav-maric: Indeed. But perhaps there is some good reason for this VC behaviour. It would seem to me that the compiler is very well able to do much more complex optimizations, yet it fails to do a very basic one here, and I wonder why. – Christian Hackl Feb 27 '14 at 19:12
  • 4
    I would have used `return Example(i == 1 ? 1 : 2);` and suspect that will allow RVO. – MSalters Feb 27 '14 at 19:15
  • 5
    @MSalters In this case. If `Example` had two constructors, with different parameter types, this wouldn't be an option. – James Kanze Feb 27 '14 at 19:19
  • This is curious. At least at one point in the past (VS 2005), RVO would not be used if there was more than one `return` in the program. – James Kanze Feb 27 '14 at 19:21
  • @James: what's at least as curious is the fact that compiling with /Od ("disable optimizations") yields the same results... – Christian Hackl Feb 27 '14 at 19:23
  • @JamesKanze: No suprise there. It gets interesting around `return Example(i == 1 ? Example(1) : Example("two"));` (Not that you'd want that, but to see how the compiler treats RVO) – MSalters Feb 27 '14 at 19:27
  • @ChristianHackl I've never used VS2013, but in \`08 and \`12, RVO usually happens in debug builds but NRVO only occurs in release builds. I'm not sure why this is happening though. I looked at the disassembly and there just doesn't seem to be any good reasons. No code is generated at all for the `Example obj1 = FunctionUsingIf(0);` but code is generated for `Example obj2 = FunctionUsingTernaryOperator(0);`. Could it be some kind of bug? – jliv902 Feb 27 '14 at 20:58

3 Answers3

5

Looking at the program output, it seems to me that, indeed, the compiler is eliding in both cases, why?

Because, if no elide was activated, the correct output would be:

  1. construct the example object at function return;
  2. copy it to a temporary;
  3. copy the temporary to the object defined in main function.

So, I would expect, at least 2 "copy" output in my screen. Indeed, If I execute your program, compiled with g++, with -fno-elide-constructor, I got 2 copy messages from each function.

Interesting enough, If I do the same with clang, I got 3 "copy" message when the function FunctionUsingTernaryOperator(0); is called and, I guess, this is due how the ternary is implemented by the compiler. I guess it is generating a temporary to solve the ternary operator and copying this temporary to the return statement.

Amadeus
  • 10,199
  • 3
  • 25
  • 31
  • Well, if I replace the ternary operator with this piece of code (creating temp with some dummy int), then I do *not* get any "copy" in the output of VC with optimization turned on. So there must be some difference; in VC, at least. The original question remains. – Christian Hackl Feb 27 '14 at 19:58
  • With optimization it actually solves the ternary at compile-time. The run-time code is just 3 calls to `std::cout<<`. If the elision that @ChristianHackl is looking for occurred, then there would only be 2 calls to `std::cout<<`. – jliv902 Feb 27 '14 at 21:35
2

This related question contains the answer.

The standard says when copy or move elision is allowed in a return statement: (12.8.31)

  • 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 cvunqualified 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 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

So basically copy elision only occures in the following cases:

  1. returning a named object.
  2. returning a temporary object

If your expression is not a named object or a temporary, you fall back to copy.

Some Interesting behaviors:

  • return (name); does not prevent copy elision (see this question)
  • return true?name:name; should prevent copy elision but gcc 4.6 at least is wrong on this one (cf. this question)

EDIT:

I left my original answer above but Christian Hackl is correct in his comment, it does not answer the question.

As far as the rules are concerned, the ternary operator in the example yields a temporary object so 12.8.31 allows the copy/move to be elided. So from the C++ language point of view. The compiler is perfectly allowed to elide the copy when returning from FunctionUsingTernaryOperator.

Now obviously the elision is not done. I suppose the only reason is that Visual Studio Compiler team simply did not implement it yet. And because in theory they could, maybe in a future release they will.

Community
  • 1
  • 1
Arnaud
  • 3,765
  • 3
  • 39
  • 69
  • This may be just another situation in which I realise how limited my understanding of C++ really is, but I thought a named object was just the opposite of a temporary (= unnamed) object. More precisely, I thought the ternary operator in my code example would yield a temporary object, because it does not have a name. If what you say is correct, then what would be other examples for an unnamed yet non-temporary object? (By the way, I think you are quoting from an older C++ standard; in C++11 the wording and paragraph numbers were changed a bit.) – Christian Hackl May 29 '14 at 09:04
  • @ChristianHackl I edited my answer to take your comment into account. – Arnaud May 29 '14 at 10:12
  • @ChristianHackl I am using the N3337 version of the Standard. This is the first version after C++11 standard was released and it is basically C++11 corrected of typos in the official standard. Which version are you using? – Arnaud May 29 '14 at 10:16
  • You beat me, I only have a draft version here which is apparently older than what you quoted. – Christian Hackl May 29 '14 at 10:30
0

I can see that it violates one general rule about RVO – that the return object (should) be defined at a single position.

The snippet below satisfies the rule:

Example e;
e = (i == 1)? Example{1} : Example{2};
return e;

But in the original expression like below, two Example objects are defined at two different positions according to MSVC:

return (i == 1) ? Example(1) : Example(2);

While the conversion between the two snippets is trivial to humans, I can imagine that it doesn't automatically happen in the compiler without a dedicated implementation. In other words, it's a corner case which is technically RVO-able but the devs didn't realize.

Dean
  • 537
  • 4
  • 8