[xKingfisher]

The article did touch on a possible reason for the misunderstanding.

If you already know from previous versions that push_back makes a copy and that C++11 added move semantics and emplace_back, it's not a huge leap to connect the two. Especially if you don't notice push_back's rvalue overload (or understand rvalues).

And if you're new to C++ and are having all of this thrown at you at once it'd definitely be easy to get some crossed wires.

[brown9-2]

As someone new to C++, it seems endlessly confusing that you are supposed to know if a function call is making a copy vs a move by figuring out the signature of the function being called or knowing which one the compiler picks, rather than being explicit about it in the code (with std::move or somehow annotating the call with what you want).

[junon]

You should always know the signature of a function you're calling. Please be reading docs.

The part I agree with are the method selection semantics. A good rule of thumb (though don't rely on it) is that the "more specific" prototype generally wins.

[brown9-2]

I agree you should know what you are calling when writing code, but there is also a need for people to read the code and understand what the behavior will be. My impression is that C++ relies a lot on implicit knowledge.

[vlovich123]

All languages do.

[Yoric]

Well, many languages try to keep this minimal. C++ doesn't.

[ziml77]

And it's nothing new with move/copy semantics either. Even passing by reference is bad for hiding that. Every time I write C++ I'm tempted to take pointers as parameters in places where you'd normally take a reference just so the call site has an indication of what I'm doing.

[xKingfisher]

It's definitely a lot to process.

I found these two articles really helpful when trying to understand moves:

https://abseil.io/tips/55 https://abseil.io/tips/77

Though I'd also say don't worry about it too much, especially at first. If you're copying a lot of temporary objects moving can get you some performance wins, but that's something profiling should be telling you m

[jeffbee]

Authors should also try to be aware that for some types there's not a meaningful difference between copy construction and move construction.

[gpderetta]

Well ideally functions shouldn't be moving behind your back, i.e if you write:

  foo(someValue);

someValue will bever be implicitly moved. Either you need an explicit cast (i.e. std move) or someValue is actually an expression returing a temporary or an rvalue.

Of course if foo takes someValue by non const reference it might still modify someValue as it wishes (and moving out of it is just one possible mutation). But this is not a specific issue with moves but with functions taking non const references in general, which should be used only sporadically and hopefully the name makes the mutation clear.