Hacker News Reader

Comment by banachtarski | Hacker News Reader

Oh boy there are some serious errors here.

Returning a stack allocated value does not invoke the move constructor. It doesn't copy either. This is a separate optimization that existed even prior to C++11 called the "named return value optimization" or NRVO for short. And by "sufficient new compiler" you really should just say every compiler. No compiler I know of in existence used by actual people doesn't implement this.

Here's a demo: http://ideone.com/QRqj5P

It's VERY important that this optimization isn't confused with move construction as the latter would actually be extremely less performant than what actually happens.

View on HN

Returning a stack allocated value is a move in C++11/14. It is also true that in many circumstances a compiler may optimize that move away using RVO/NRVO.

Consider this example: http://ideone.com/T872Oj

In F1 the compiler can NRVO away the move.

In F2 it cannot.

Both will fail to compile if you delete the move constructor.

Does that mean that side effects in a move constructor is undefined behavior since you can't know whether it's going to be called?

Edit: I see that StephanTLavavej clarified that below.

Also known as copy elision. This subject is surprisingly so obscure, that I literally had to read the C++ standard to have a good grasp of it. Combine it with general move semantics, and things start looking pretty complex.

> Returning a stack allocated value does not invoke the move constructor.

Unless the 'named return value' you're returning happens to be a named parameter.

Example: https://ideone.com/TddXn7

The move here actually comes from the return, not passing in the newly constructed object. The compiler is eliding Foo's move constructor in main(), but it can't elide both... even if the function is fully inlined.

Yes good point. NRVO doesn't apply here and named parameters are in fact moved or copied depending on if they are passed by value or by reference.

In your case a move would happen but if you changed the parameter to a reference I think it would copy.

Yes it would copy, unless you used an explicit std::move(). This is why most of the time you're better off just passing things around by value, and making your classes cheap to move (by, force example, making use of pointers (smart or otherwise)).

This results in less code and more manageable semantics.

I think this is due to a confusion between the two kinds of "move" in the article.

Returning a value from a C++ function is a "move" in the Rust sense. It's not a move in the C++ sense, since C++ moves involve move constructors.

It's probably this confusion that led to it being written that way, probably should be fixed.

He has a line where he writes

    return val; // val is `rvalue` here

This is the part that isn't accurate. "val" is a named reference and is not an rvalue. There isn't any "moving" up the stack that happens. He's likely confusing this with an expiring value (a subtype of rvalue) that happens in code like

    foo(returns_something());

The returned value from returns_something() is un-named and is about to die after this line executes (lives until foo's invocation unwinds) and so it is an rvalue. You can't have a named rvalue unless you std::move explicitly I don't think.

It's a little more subtle than that. "val" is definitely an lvalue. However, when returning a local variable like this, C++11 has a rule: "if the NRVO activates, there are no copies/moves. Otherwise, see if you can treat val as an rvalue - if so, you get a move. That almost always works, but if it doesn't, fall back to treating it as an lvalue so it compiles with a copy like it used to."

This is the one time in the language that lvalues are automatically moved from, and it's because the language/compiler knows that returning from a function will destroy all local variables, so it's safe to move from them.

I see that makes sense. I wonder if at some point we should go back to the drawing board on whether the names "lvalue" and "rvalue" make sense. I keep on going back to the mathematical LHS and RHS semantics to figure it out but I can see why other programmers and myself get confused on these sorts of specifics.

Giving the compiler the ability to move implicitly surprises me since moves can have side-effects as you've said.

I know. I'm not saying it isn't wrong, I'm saying that I can see why he wrote it that way :)

A lot of C++ resources explain moving solely in terms of rvalues so it's easy to associate the two in the wrong places.

To be fair NRVO is now in the c++ standard. prior to c++11 it was a non-mandatory compiler optimization. Now it's part of the language. It's a good think because optimizations should have no side-effects yet this one does (if your copy ctor has a print statement, it won't be printed if this optimization is deployed.)

Did you look at the generated assembly of your demo? RVO probably didn't happen there. "returns_a_foo" was most likely inlined into main and then there was no need of eliding a copy.

I'm not saying that you are wrong, only that your demo poorly demonstrates what you are arguing.

This is why I love HN.

> This is a separate optimization that existed even prior to C++11 called the "named return value optimization" or NRVO for short. And by "sufficient new compiler" you really should just say every compiler.

Aren't copy elision guarantees part of the new C++17 standard?

Yes but they've "practically" been happening already since the C++03 era

On a bunch of platforms in many cases. If in doubt, check produced assembly.

Thanks for your comment, looks like my knowledge is still lacking here. Although I hoped that it would be enough to give an overview, without going into much detail.

I have removed a bit where I say that rvalues are same as returned values, to avoid confusing other readers.

Another nitpick:

    However, if the name was a very big string, i.e. something like file contents, and it would be necessary to ensure no copies for performance reasons, the unique_ptr or shared_ptr would come to the rescue

This is also not true at all. You can choose to provide a non-templatized function that only accepts an rvalue reference. For example, http://ideone.com/055ViY does not compile.

The purpose of the smart pointers unique_ptr and shared_ptr is to annotate ownership for heap allocated objects (unique vs shared ownership). They do help alleviate the thing you're describing, but shouldn't be used so liberally in that way since they heap allocate!

You can implement explicit stack pools more easily now in C++17 thanks to PMR. Just remember that platforms have a stack length limits and that such a pool is essentially a global variable you may have to handle.

No problem :) It's still a good effort nonetheless and I'm sure your readers will appreciate the corrections. I personally also learn the most through writing

Bjarne Stroustrup rates his own C++ knowledge as 7/10, if that makes you feel better.

Even Borland Turbo C++ from 1992 did this: https://youtu.be/RWavTVo7D3M?t=496

Yes, but rust on LLVM will also perform NRVO, will it not?

NRVO is a compiler optimization, not a feature of the language itself.

Copy elision, including the RVO and NRVO, actually has to be blessed by the language (there is a paragraph in the C++ Standard dedicated to it). That's because copy elision skips calls to copy constructors and destructors, which are "observable" (they can have side effects, including printing stuff to the console, etc.). The general "As If Rule" permission to optimize "unobservable" things away doesn't apply here, so special permission to drop the calls is required. This is true going back to C++98 (C++17 strengthened things with guaranteed copy elision).

Ah and here's the man I originally learned a lot of these concepts from haha. And TIL. I remember programming back in the C++98 days and people were terrified of the copy on return. I had always assumed there was a reason for it but I suppose people might not have understood the behavior super well or I was misinformed at the time.

Part of it was surely programmer confusion, but old compilers in the C++98 days were also worse about implementing the RVO/NRVO. For example, MSVC didn't implement the NRVO until 2005.

Well, the C++11 standard requires the Compiler to elide the copy (NRVO) if it wants to, or move if it doesn't want to. The language used is very lawyerish, I had to read the section a couple of times to find it even though I knew it was there (it's mentioned in "Effective Modern C++").

So it's up to the compiler to elide the copy (making it a compiler optimisation as you say), but the standard says that it has to move if it doesn't elide. This means that returning a named loca variable by value is always the best choice. Again, see "Effective Modern C++" for more.

It's a language feature if your language has copy and move constructors.

Rust doesn't, so it's just an optimization. In C++ the code will have different semantics (e.g. if your move ctors have side effects) based on this optimization, so the language needs to define if/how it works.

I'm not saying Rust doesn't do this. I'm not familiar with Rust but many languages do NRVO as you point out. The important distinction is whether we actually run additional instructions in this variant of the optimization. In C++ at least, no additional instructions are run.

Rust doesn't have user-defined copy constructors and a return is always a move (semantically a memcpy), so I'm not sure it's so relevant as an optimisation for Rust.

NRVO is an optimization above a move, at least in C++. Most compilers simply toss a pointer to the returned to 'object' on the call stack for direct manipulation (correct me if I'm mistaken compiler peeps!), avoiding the extra potential internal surgery involved in a move operation.

You can't manually implement the `Copy` trait?

You can but it has no user-defined methods related to it, it's just a marker trait. Move and copy are both straight memcpy, the difference is whether the source remains valid afterwards, not what operation is performed.

Kinda but:

    trait Copy: Clone {}

Copy is nearly always done by memcpy/memmove. When Copy is invoked it won't use the `Clone::clone` method: https://is.gd/2hMyNP. i.e. Clone is always explicit.

Added: Essentially Copy is the same as a move, but the original value is still valid.

That makes a type copyable, but does not allow you to insert arbitrary code that must be executed during a copy.

The compiler I work with doesn't do this optmization in every case, so I can't rely on it. Compilers for embedded platforms are shit.

Reply on news.ycombinator.com