5

For performance reasons I'm interested in making sure that RVO is being performed on the return values of functions. What would prevent this optimization from being performed by a modern C++ compiler (such as gcc, clang, and msvc 2015) which I should worry about?

Clarification Edit: What I am interested in is identifying (hopefully eventually through some form of static analysis, but that can come later) when a particular value with an expensive copy constructor (but a cheap move constructor) is being returned from a function, and RVO is not performed (meaning that an unnecessary copy constructor invocation is being performed). This is especially the case when a std::move() invocation could avoid this expensive operation.

I'm interested specifically in the situations when it is actually performed by compilers, rather than the situations where it would be allowed by the C++ 11 specification, which I imagine are more broad than the situations actually implemented. I am also interested in situations where the compiler automatically uses the move constructor rather than the copy constructor (If that is allowed).

Mystor
  • 365
  • 3
  • 9
  • 4
    Are you asking in which situations compilers don't implement it when it is allowed, or are you asking for the rules specifying when it is allowed? – juanchopanza Jun 18 '16 at 22:37
  • You might take a look at what [this proposal](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0135r0.html) aims to guarantee. – chris Jun 18 '16 at 22:37
  • RVO is not just copy elision in the calling code but the case where an object created before the `return`, is created directly in storage provided by the caller. For this to happen the compiler must know that this object will eventually be returned. Conversely, when that knowledge isn't available or is too costly to obtain, then RVO cannot happen. The result can still be moved, though, if that applies. – Cheers and hth. - Alf Jun 18 '16 at 23:21

0 Answers0