How would a compiler optimize temporary objects away?

Question

I am reading about move semantics and this code is given:

#include <iostream>

using namespace std;

vector<int> doubleValues (const vector<int>& v)
{
    vector<int> new_values;
    new_values.reserve(v.size());
    for (auto itr = v.begin(), end_itr = v.end(); itr != end_itr; ++itr )
    {
        new_values.push_back( 2 * *itr );
    }
    return new_values;
}

int main()
{
    vector<int> v;
    for ( int i = 0; i < 100; i++ )
    {
        v.push_back( i );
    }
    v = doubleValues( v );
}

So the author states that after the return of doubleValues, there could be up to two copies happening

one into a temporary object to be returned, and a second when the vector assignment operator runs on the line v = doubleValues( v );

He also states that the first copy may be optimized away.

Here is what I do not get:

• What does he mean when saying "one into a temporary object to be returned"? Isn't it a temporary object that is returned by the function? If so, I do not see why anything should be copied to another temporary object.

• He states that this temporary object could be optimized away. How would a temporary object be optimized away, like what is considered an optimization?

Answer 1

It is important to understand that what a compiler must do and what a compiler can do are as different things as what a piece of code formally means and what it really means.

Take a much smaller and easier example, right from the code snippet you posted: i++.

What your code formally means is: Make a copy of i, then increment i, and have the expression have the value of the copy that you made previously.
What your code really means is: Increment i and screw the rest (because I'm not using the result).

What the compiler must do is implement exactly the (externally visible) semantics of the "what your code formally means" part. None more and none less.
What the compiler can do is incrementi and screw the rest (because nobody can tell the difference).

Generally, a compiler may make any changes it likes based on the "as if" rule, which, sloppily means that as long as the externally observeable behaviour stays the same, nobody cares. Move semantics are a means to bend the rules a bit further, both implicitly and explicitly.

When you move an object rather than copying it, you are basically cheating. However, the difference between "cheating" and "magic" is whether you're being caught or not (just like the difference between "genius" and "madness" is defined only by success).
You're abusing an object that is going to be destroyed the next instant anyway, claiming it's a copy when it is not. However, nobody will notice because the moved-from object is a rvalue, i.e. it has no name (and thus isn't otherwise accessible) and is destroyed right away, too. On the other hand, the new object that you present to the world which isn't new at all, but it is nevertheless a perfectly good object by all means (the original one!). That's the whole trick.

About your second question: Your doubleValues function takes a std::vector by constant reference. That's not a copy, it's as cheap as a pointer. However, then you copy all the values into a new object new_values.
Then, you return that object by value, which means you formally make a second copy, and finally you invoke the assignment operator of std::vector, which, actually, is even a third copy.

Formally, that is. An optimizing compiler may, and hopefully will, optimize that away (NRVO).
Used to be compilers would only do that with unnamed temporaries, but that was like... 10 years ago. Nowadays, named return value optimization usually/often "just works", luckily.

Under some conditions (although not in your example), the compiler is even required to perform copy elision per the latest standard.

Answer 2

You need to understand that if a function returns a value by value, then it is returned via a temporary. It means, a non-optimizing compiler will:

1. copy new_values into a temporary, at return
2. copy from this temporary to v at the last line if main()

The standard permits a compiler to elide any of these copies, if it can. For example, it can pass a hidden reference parameter to v in doubleValues, and doubleValues can use this hidden reference instead of new_values. This way, no copy will be performed.

Note: a c++11 compilant compiler will use move instead of copy