Why don’t more C++ developers talk about Return Value Optimization (RVO)? This optimization has existed in C++ since 1997, yet many developers still assume returning objects is expensive. Let’s take a simple case. A function creates an object and returns it: MyClass Myfun() { return MyClass obj; } Without optimization, you might imagine this happening: • create obj inside Myfun() • copy it when returning to main() • destroy the local object That sounds like extra work, right? Here’s the interesting part. Modern C++ compilers apply Return Value Optimization (RVO). Instead of: create → copy → destroy The compiler simply constructs the object directly in the caller’s memory. So the object is effectively created inside main() from the start. No extra copy. No unnecessary destruction. A subtle optimization — but one that makes returning objects cheap and idiomatic in C++. Small compiler optimizations like this are why understanding how C++ actually works under the hood matters. Did you learn about RVO early, or much later in your C++ journey? #CPP #SoftwareEngineering #Programming #SystemsProgramming #Developers
This can also be an example of inline function, they perform operations without creating its own stack frame. But uses the caller's stack frame... I guess CPU still allocates stack frame for the normal function even after RVO
Come in to my profile, you'll find me talking.
RVO is mandatory from C++17, before then you were dependent on the compiler generosity.
And this is why return std::move(obj); is a huge anti-pattern. Many people do this mistake. Using move in return you force the compiler to create another copy and move between them. The truth is that RVO/NRVO is even more efficient that move semantics. Also I would suggest to get rid of the name in your source code. Try this: return MyClass(); In this case you replace RVO with NRVO. The former is just recommended by the C++ standard and left for a compiler decision. The latter is mandated by the standard for compilers to apply.
That’s why experienced programmers don’t return structs / classes directly. Instead they don’t rely on compiler optimizations and hence use the envelope pattern / dependency injection in order to work directly on the callers storage for expensive operations on large structs / storage… Pro: It is efficient even on non optimized / debug code… 😉
"Premature optimization is the root of all evil" (Donald Knuth) Sorry, but RVO is NOT important. I teach it. But its existence is not the real lesson. The real lesson is that these kinds of optimizations happen all over the language and the compiler + optimizer will (almost?) always do a better job than manually trying to optimize the code - SO DON'T WASTE TIME ON OPTIMIZATION ATTEMPTS!
More examples: C++ Weekly With Jason Turnerer C++ Weekly - Ep 456 - RVO + Trivial Types = Faster Code youtu.be/DzUAqXMUjtc
Because C++ is not Java 🤪 😁. On a serious note, I think NRVO is optional for the compiler. In my experience is a waste of time when using modern C++ (>17) since there is a form or another of optimization, unless you have a very specific reason but those cases are as rare as planet alignments :).
The only optimizations one can rely on are the ones mandated by the standard :)