0

RVO is a compiler optimization but can provide a really useful performance boost. However it is not guaranteed and cannot be relied on.

Is there anything in the language standard itself can optimize return value? Move semantics still copies the members values, correct?

CB Bailey
  • 755,051
  • 104
  • 632
  • 656
SwiftMango
  • 15,092
  • 13
  • 71
  • 136
  • 3
    Move semantics implies doing as little copying as possible. It's often just pointer swapping. – cHao Dec 20 '13 at 04:06
  • I'd say RVO can be relied on in a lot of cases unless you're using an ancient compiler. Any compiler modern enough to support move semantics should have a good grasp on RVO. And move semantics *moves* things. This could be the same as a copy if there's no way to take advantage of the moved-from object never being used again, but it's often much faster. – chris Dec 20 '13 at 04:22

2 Answers2

2

C++11 has the guarantee of implicit move when returning from a function in certain ways.

In addition, you can directly construct the return value using any implicit constructor via return {a,b,c}; syntax.

Finally, rvo if it fails becomes an implicit move, and the first implicit move above is often turned into nrvo, so the techniques align nicely.

Yakk - Adam Nevraumont
  • 262,606
  • 27
  • 330
  • 524
  • Can you please expand a bit on the first sentence? – SwiftMango Dec 20 '13 at 06:07
  • 1
    @texasbruce: The C++11 standard 12.8/32 requires that "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". – Michael Burr Dec 20 '13 at 07:19
2

I don't know if I misunderstood your question, but (N)RVO is in fact "in the language standard itself". This is called copy elision and described in §12.8.31.

Indeed move construction is more computationally expensive than RVO, because as you said it still has to "copy" the member variables from one memory location to another (shallow copy of the object). RVO eliminates these read/write actions entirely.

(N)RVO works in the majority of cases, and where it can't (when a function can return one of multiple variables) move construction kicks in.

AFAIK there is a consensus that all cases of "optimizing return value" as you call it are sufficiently covered since C++11

Erik van Velzen
  • 6,211
  • 3
  • 23
  • 23
  • I found copy elision in 12.8.31 in N3337 Current standard... and it says copy elision is `permitted` , but not forced.. – SwiftMango Dec 20 '13 at 07:30
  • It would be weird if the standard would make optimizations mandatory. It's just not the right place. All serious compilers do RVO anyways. – Erik van Velzen Dec 20 '13 at 07:37
  • 1
    @ErikvanVelzen unlike other optimizations, NRVO/RVO has observable side effects: other optimizations are "as-if", while NRVO/RVO can change program behavior significantly. I suspect that eventually it will become mandatory to do NRVO/RVO. – Yakk - Adam Nevraumont Dec 20 '13 at 14:39
  • @Yakk honestly even if it becomes mandatory it's still a minefield. It's a good strategy to avoid writing your own move/copy constructors and assignment operators and never let them have side effects. The only exception I can think of is when you are writing a container. – Erik van Velzen Dec 24 '13 at 00:38