Hacker News Reader

Comment by jnordwick | Hacker News Reader

Part of the problem with the new move semantics for me, and C++ in general, is figuring out what the compiler is going to do and their interaction with the return value optimization. Sometimes I can't figure out if the RVO or the move constructor is going to be used.

C++ has definitely blown it's complexity budget and the problem is getting worse. I don't really see a way out of it either. I sure hope Rust starts to gel or a better C++ comes along, because I don't think I can keep pace with C++ too much longer.

View on HN

If you're using clang you can just turn on -Wpessimizing-move and the compiler will tell you when you have a std::move call that is inhibiting RVO.

The rule of thumb is don't use std::move on a return value unless you are returning a move-only type (which forces you to do so).

> The rule of thumb is don't use std::move on a return value unless you are returning a move-only type (which forces you to do so).

RVO will be automatically applied if the returned variable is local to a function and of the same type as the function's return type. That's all that the standard allows.

RVO is not applied to function arguments, regardless of whether or not they're rvalue references.

So your rule of thumb breaks for cases such as these (X is a movable and copyable type):

    X f(X&& x) {
      return x;  // x is copied, not moved
    }

In order to get x moved into the return location, you would need to do move it explicitly.

Source: Effective Modern C++ by Meyers.

btw, -Wpessimizing-move is included in clang's -Wall warnings. clang's warning documentation is poor, but the source code shows that -Wpessimizing-move and -Wredundant-move are included in -Wmove, which is included in -Wmost, which is included in -Wall:

https://github.com/llvm-mirror/clang/blob/master/include/cla...

I reacted like that at first, and then later on I realized that in order to use containers on classes, I either have to use pointers and manual allocation or accept wasteful copies. The move semantics simply allows to mimic a copy without actually doing it, when you plan to discard your initial object. A common situation when populating a container with class instances.

I had a long back and forth relationship with C++. I have the same criticism everyone has: it is hard to use, hard to understand, there are tons of possibilities and concepts that overlap each others, many ways to do the same things that are sometimes incompatible...

But reading more about it, getting updated on the more recent iterations, I understood that C++ is more than a programming language: it is actually a quest. It is a search for a language that can both manipulate high-level concepts and also descend to the very low level required for software living close to the hardware (you'll do mostly C there but a few C++ constructs can be surprisingly useful)

Most other languages will specialize in a niche. C++ developers want to be able to express the most abstract concepts in the best possible implementation. That's a quest for the grail. Few other languages dare to dream that big. And of course C++ stumbled sometime along the way, still limping from backward compatibility, but it is so far the most advanced in this quest.

> Part of the problem with the new move semantics for me, and C++ in general, is figuring out what the compiler is going to do and their interaction with the return value optimization.

It's very simple:

If you return something that can be moved, it will be moved, always.

[N]RVO is something that may or may not happen. However, if you don't write code that does crazy things (like auto_ptr style copy constructor that actually moves), at most, it'll result in an extra copy/move that is redundant and won't change semantics. So you should never care about whether it happens or not.

> If you return something that can be moved, it will be moved, always.

How about the example I gave in my reply to your sibling? https://news.ycombinator.com/item?id=12578621

Good point. Let me correct that: if you return something that doesn't have a name, or is a local variable in the function you're returning from, it will always be moved. Usually it amounts to the same thing, except when non-const lvalue or rvalue references are involved (but it's fairly rare to return via a non-const reference).

So when I said RVO, I mean't NRVO too (but not from an argument passed in).

Wouldn't looking at the generated assembly work? If performance matters to the level of caring about RVO in a specific instance, looking at the assembly can't be avoided.

I agree it's inconvenient, ideally a compiler should do the right thing, but there are no such smart compilers yet :)

> Part of the problem ... is figuring out what the compiler is going to do

Not meant to offend you, but that should not be any of your business :-)

I disagree. C++ has never had a clearly defined abstract machine, or a common virtual machine. Knowledge of what is actually going to happen is necessary if one needs high performance in anything other than trivial circumstances, and knowledge of what the compiler is going to do is part of that. In C++, there are times when it very much is our business to know how our tools work and what they're going to do.

There are languages in which not knowing what the tools are going to do is never a concern. C++ isn't one of those languages.

I've been several times in the situation of having to push the language to its limits for performance, and gcc documentation was of great help. But, maybe it's a nice property of gcc, maybe it's a nice property of gcc's documentation, I never felt I had to learn some dirty trick for gcc in particular. I always understood the principle behind the implementation, and the code I wrote as a consequence was better in principle, too.

Summing up, knowing your tool is a must, but if you find yourself doing its job, than it's time to at least question your choice.

When micro- and nanoseconds matter, it is your job to dig into the ugliness of the generated code, if it is C/C++/Rust or even if it is Java.

> I don't really see a way out of it either.

Stop using C++ unless forced to do so.

That's the only way to leave the complexity minefield.

Heh, I think this isn't complex as much as making something complex simpler. Just super awkard because it's caked in afterwords. I'm happy to see some good examples of move constructors and the like.

Reply on news.ycombinator.com