How to check for C++ copy ellision

Question

I ran across this article on copy ellision in C++ and I've seen comments about it in the boost library. This is appealing, as I prefer my functions to look like

verylargereturntype DoSomething(...)

rather than

void DoSomething(..., verylargereturntype& retval)

So, I have two questions about this

1. Google has virtually no documentation on this at all, how real is this?
2. How can I check that this optimization is actually occuring? I assume it involves looking at the assembly, but lets just say that isn't my strong suit. If anyone can give a very basic example as to what successful ellision looks like, that would be very useful

I won't be using copy ellision just to prettify things, but if I can be guaranteed that it works, it sounds pretty useful.

Answer 1

The only way to know for sure is to look at the assembly, but you're asking the wrong question. You don't need to know if the compiler is eliding the copy unless it matters to the program timing. A profiler should easily tell you if you're spending too much time in the copy constructor.

The poor man's way to figure it out is to put a static counter in the copy constructor and try both forms of your function. If the counts are the same, you've successfully avoided the copy.

Answer 2

Google "Named Return Value Optimization" and "Return Value Optimization" instead. Modern compilers will in fact not perform the copy in many cases.

You can check if it's occurring by returning a type with side effects -- such as printing a message. Wikipedia has some good examples of where program output changes when RVO and/or NRVO is in effect.

Answer 3

From your cited article:

Although copy elision is never required by the standard, recent versions of every compiler I’ve tested do perform these optimizations today. But even if you don’t feel comfortable returning heavyweight objects by value, copy elision should still change the way you write code.

It is better known as Return Value Optimization.

Answer 4

I think this is a very commonly applied optimization because:

1. it's not difficult for the compiler to do
2. it can be a huge gain
3. it's an area of C++ that was a commonly critiqued before the optimization became common

If you're just curious, put a debug printf() in your copy constructor:

class foo {
public:
    foo(): x(0) {};

    foo(int x_) : x( x_) {};

    foo( foo const& other) : x( other.x) {
        printf( "copied a foo\n");
    };

    static foo foobar() {
        foo tmp( 2);

        return tmp;
    }


private:
    int x;
};



int main()
{
    foo myFoo;

    myFoo = foo::foobar();

    return 0;
}

Prints out "copied a foo" when I run an unoptimmized build, but nothing when I build optimized.

Answer 5

To answer question 2, you could write a demo program where you write a class DemoReturnType; which has instrumented constructors and destructors which just write to cout when they are called. This should give you enough information about what your compiler is capable of.

Answer 6

Example of what it looks like:

#include <iostream>

struct Foo {
    int a;
    Foo(int a) : a(a) {}
    Foo(const Foo &rhs) : a(rhs.a) { std::cout << "copying\n"; }
};

int main() {
    Foo f = Foo(1);
}

If you see no output, then copy elision has taken place. That's elision of a copy from an initializer. The other legal case of copy elision is a return value, and is tested by:

Foo getFoo() {
    return Foo(1);
}

int main() {
    Foo f = getFoo();
}

or more excitingly for a named return value:

Foo getFoo() {
    Foo f(1);
    return f;
}

int main() {
    Foo f = getFoo();
}

g++ performs all those elisions for me with no optimisation flags, but you can't really know whether more complex code will outwit the compiler.

Note that copy elision doesn't help with assignment, so the following will always result in a call to operator= if that operator prints anything:

Foo f(1);
f = getFoo();

Returning by value therefore can still result in "a copy", even if copy constructor elision is performed. So for chunking great classes it's still a performance consideration at the design stage. You don't want to write your code such that fixing it later will be a big deal if it turns out your app spends a significant proportion of its time in copying that could have been avoided.

Answer 7

Rvalue references solve this problem in C++0x. Whether or not you can obtain an rvalue-enabled compiler is another question - last time I checked only Visual Studio 2010 supports it.