In simpler terms

1. You must implement a move constructor or a move assignment operator in order for std::move to do anything

2. The moved object could be left in an unusable state, depending on your implementation, after stealing its internal resources.

I read Effective Modern C++ years ago and was confused exactly like what you describe.

I thought "move doesn't move" was a fairly common C++ mantra at this point.

Modern C++ is hard to get into for people who learned C++ in the 90s and then worked in other languages for a decade or two.

Throwing move is super weird too. I believe that it was a mistake to not treat user move like C++11 destructors and default to noexcept(true) on them. But it is what it is.

On the other hand, writing special member functions at all(move & copy constructor/assignment, destructor) is a smell for types that don't just manage the lifetime of an object(unique_ptr like things). People should not generally be writing them and being open to the mistake of getting noexcept wrong.

The reason performance-noexcept-move-constructor is not enabled by default is likely because blindly applying noexcept is dangerous if the underlying logic isn't actually exception-free. If you let clang-tidy slap noexcept on a move constructor that does end up throwing (perhaps because it calls into a legacy member or allocates memory internally), the runtime behavior changes from caught exception to std::terminate().

Most sensible Compiler flags aren't enabled by default... I keep a list of arguments for gcc to make things better, but even then you'll also wanna use a static analysis tool like clang-tidy

performance-noexcept-move-constructor is great but it also complains about move assignment operators, which are completely different beasts and are practically impossible to make noexcept if your destructors throw.

  match cxxConstructExpr(hasDeclaration(cxxConstructorDecl(isMoveConstructor(), unless(isNoThrow())).bind("throwing-move")))

If I'm not mistaken, all the pitfalls in the article have clang-tidy lints to catch

Nothing about clang-tidy is enabled by default, and getting it to run at all in realistic projects is quite a chore.

c++ 03 was a lot easier.

For instance, if you want to avoid unnecessary copy operations when returning a string, just return it in variable that you pass by reference (eg. void doSomething(string& str);) likewise avoid the vector class making unnecessary copies, simply by creating the objects on the heap and use a vector of pointers instead of values. It's a bit more ugly, but it works, and you don't need to read a 24 page blog to understand all the corner cases where it can go wrong. modern c++ is all about syntactic suger.

I write c++ for a living and I feel the same way. And many c++ codebases have that OOP AbstractObjectInterfaceFactory stink which makes it even worse

I understand the individual rationales of C++ things but I lost the faith on the whole thing.

Systems programming in the large is hard, owning the category for decades harder still.

Even languages that have tried to fast-follow and disrupt C++ end up looking a lot like C++. There is an irreducible complexity.

Same. I’ve read all the books. Written all these things at least a few times. It’s just not doable post C++11.

C++ is a universal tool with long history. So yes it makes it very complex for various reasons. However it does not preclude one from being productive. I do not come anywhere close to being expert in C++. Still write software that blows the shit out of competition. I have general understanding how the things work and when I need some particular feature I just look up the efficient way of doing it in whatever language. Not just for C++. I actively use many languages. My goal is to deliver good software and get paid by happy client, not to know every little detail of the tools I use, it is just impossible and serves no useful purpose.

Value categories actually just are confusing in a language as complicated as C++. I'm not willing to bet that even senior C++ developers are always going to be able to deduce the correct value category.

And worse, in typical C++ fashion, there is still little guaranteed as far as when std::move will actually cause a move. The implementation is still given a lot of leeway. I've been surprised before and you basically have no choice but to check the assembly and hope it continues to be compiled that way as minor changes make their way into the code base.

The issue TFA is describing isn't really about not understanding move semantics, it's about not having read the documentation for the STL container classes, and not therefore realizing that anything requiring reallocation needs a noexcept move constructor (else will fall back to copy construction).

Note that a move constructor that is NOT declared with noexcept is perfectly valid, and will happily be used most of the time (other than where code, such as the STL, is explicitly looking for a noexcept one).

So, for example:

HeavyObject t;

HeavyObject s(std::move(t));

Will cause t to be moved to s.

Coming from other languages with generics, it took a while for me to internalize SFINAE when writing templated code.

That still leaves the problem of when to use std::swap vs ordinary assignment in generic (i.e. templated) code.

Like when std::vector needs to resize its underlying storage (as a result of push_back, for example), it has to decide which approach to use to copy/move items from the old storage to the new storage.

For std::vector<std::string>, std::swap would probably be at least ok if not optimal, but for std::vector<int> it would be overkill and therefore decidedly non-optimal. In the latter case, you want to do memcpy(new, old) and be done, not std::swap(old[i], new[i]) for each int.

I think a lot of the motive for adding move semantics to c++ has to do with giving the compiler enough information to produce results that are both optimal and correct in generic code.

my take looking at languages beyond C++ is a very different one

you want a well working general solution which works well (most of the time for most of the "generic code" (i.e. good defaults for the default use-case).

and then add escape hatches for micro-optimizations, micro-control etc.

C++ on the other hand was deeply rooted designed with micro optimizations and micro control first.

"Generic solutions" where then tried to be added on top, but not by changing a badly working abstraction/design but by adding more abstraction layers and complexity on top. And with a high requirements for back/forward compatibility, not just with the language but ton of different tooling. That this isn't playing out well is kinda not really surprising IMHO. I mean adding more abstraction layers instead of fixing existing abstraction layers rarely plays out well (1) especially if the things you add are pretty leaky abstractions.

-----

(1): In context of them archiving overall the same goal with just different details and no clear boundaries. Layering very different kind of layers is normal and does make sense in a lot of situations. Just what C++ does is like layering "a generic system programming language" (modern C++) on top of "a generic system programming language" (old C++) without clear boundaries.

In C++17 and later, return std::move(local_variable) as opposed to return local_variable is only breaking NRVO (which avoids even having to move, by essentially replacing local_variable with a reference to the variable the caller is assigning the function result to).

In C++17 if you do return std::move(local_variable) it will do exactly what you asked for and move the local variable to the return value, which with copy elision means directly to the caller's variable.

So, return std::move(local_variable) is only preventing NRVO, it's not preventing a move (even though you shouldn't be asking for a move, because move is not the most efficient way).

That has about the same issue: like std::move it doesn't really explain that the receiver decides.

There is no giving (or taking).

I think std::rvalue would be the least confusing name.

The name predates the standardisation. The committee did not come with the whole thing themselves, rather they adopted and expanded already existing library implementations. You could move in C++, with this exact name, long before C++11.

See, for example, this implementation https://stlab.adobe.com/group__move__related.html

std::movable

Split the difference with std::moveable().

Also signals it doesn't actually move, while remaining just as fast to type.

But that misses too much of the semantics. It also implies ownership transfer, even if copied.

thanks to the incredible advances in terms of developer tooling over the last 50 years (i.e. tab-autocompletion) there should be no difference in writing those two.

std::rvalue

I think there's a consequence difference between the IDE being sure enough that a std::move is warranted to issue a lint, versus the compiler being 100% provably certain that inserting a move won't cause any issues.

> So, what are the forces that have determined the current state of C++?

I'm very confident that the main driving factors are:

1. "performance" (not wanting to do more allocations than necessary)

2. abi compatibility

3. adding features without caring how well they integrate

Example for 1:

"emplace", you normally have "append" but emplace directly constructs the object in the container instead of having to be constructed first and then moved into the container. This nice and all but breaks when using pairs (for reasons you can google but I don't wanna explain here). So now you have these obscure classes like https://en.cppreference.com/w/cpp/utility/piecewise_construc... which solve this.

Example for 2:

Basically they never break the ABI and this leads to tons of old stuff hanging around and never being changed and just more stuff being added on top. std::iostream is famously slow and a big reason is because you can't fix it without breaking the abi which they don't wanna do.

Example for 3:

The whole template thing adds so much complexity it's bonkers, I think c++ without templates would be pretty manageable comparatively. For example because C++ has constructors and they don't quite mix well with templates you suddenly end up in the situation that you have 2 concepts: "normal" template argument deduction and constructor template argument deduction (CTAD). Because of this asymmetry you need a custom language feature called "deduction guides" to maneuver yourself out of the problems that come from this.

Or another short one: std::expected without something like the "!" that rust has. You end up with endless "if(result.has_value()) { return result; }" cascades and it's horribly unergonomic. So now we have a Result class but it's practically unusable that it will only fragment the ecosystem even more.

Note that C# 14 versus C# 1.0 isn't suffering from feature creap as well.

What has guided C++ are the 300+ volunteers that get to submit papers, travel around the world attending the meetings, and win the election rounds of what gets into the standard.

Unfortunately design by committee doesn't lead to a clear product roadmap.

> So, what are the forces that have determined the current state of C++?

A subset of the language aimed at library writers. As a user of those libraries all these weirdo features are likely to be transparent.

> old style "C with classes" C++ as being fairly small and elegant

it (C++) never really was that

but it was possible to use it "as if it where that" (kinda, e.g. there is code which is valid in C but UB in C++)

I mean there where also times where books which told you that in C everything "is just bits in memory" where popular/believed/beloved, even through that never really was true outside of some very specific cases (all of CPU without caches, only in order execution, single core, a mostly non-optimizing compiler, and other requirements). It was just that the chance to run into issues was much less likely if you go ~20+ years back into the past so you could kinda use it like that (at some risk, especially wrt. forward compatibility).

Today you find ton of material even about obscure features, complications, hidden food guns, etc. so things do look/feel far more overwhelming IMHO.

That modern C++ is a bit like a different language glued on top of old C++ doesn't exactly help either.

I'm convinced naming things is equivalent to choosing the right abstraction, and caching things is creating a correct "view" from given normalized data.

> C++ smart pointers (eg std::unique_ptr<>) are likewise to handle ownership and incur a runtime cost where in Rust they are handled by the compiler with no runtime cost.

What additional runtime cost is incurred by the use of std::unique_ptr? Either compared to Rust or compared to doing manual memory management in c++?

The article explains this.

std::move itself doesn't move ownership, though. It allows the compiler to transfer ownership to the receiver of the value, but it doesn't force it in any way. This is important, because it means YOU may still be the owner of a value even after you called std::move on it.

Not to mention, ownership in C++ is not entirely lost with moves in the traditional sense. For example, your code still has to destruct the object even if you did move it to somewhere else.

Std move doesn’t move ownership. It simply casts into something that could have its ownership taken. Whether or not that actually happens is impossible to identify statically and the value after ownership is consumed is unspecified - sometimes it’s UB to access the value again, sometimes it’s not.

    void foo(Obj && arg) {}

    void some_function(std::vector<int> &&);
    void some_function2(std::vector<int> &&);

    void main() {
        std::vector<int> a = { 1 };
        some_function(std::move(a));

        a.push_back(2);
        some_other_function(std::move(a));
    }

    void foo(std::unique_ptr<int, Deleter>&& p) {
        std::random_device rdev {};
        auto dist = std::uniform_int_distribution<>(0, 1);
        if (dist(rdev)) {
            auto pp = std::move(p);
        }
    }

  void foo() {
    std::random_device rdev {};
    auto dist = std::uniform_int_distribution<>(0, 1);
    if (dist(rdev)) {
      int res = 1 + 2;
    }
  }

Well, no, because CAN take isn't the same as WILL take.

Changing something to an rvalue means it'll now match a move constructor, but there is no guarantee a move constructor will be used, even if defined, because you've got classes like std::vector that are picky and are explicitly looking for a noexcept move constructor.

std::allow_move probably would have been a more accurate name for std::move.

Personally I see std::move more like removing ownership because it’s not explicit from its call where the ownership is transferred.

  std::string abc = "abc";
  std::move(abc); //doesn't remove ownership or do anything really
  std::print(abc); //guaranteed to print "abc"

> Rust’s borrow checker doesn’t actually borrow anything either

Why would it? It's called the borrow checker, not the borrower. So it checks that your borrows are valid.

std::move looks and feels like a function, but it doesn't do what it says, it makes objects movable but does never moves them (that's up to whatever is using the value afterwards). If you want something similar in Rust, Pin is a much better candidate.

There was no Rust in 2011.

What’s the problem? It makes perfect sense to me that a const object cannot be moved from, since it violates the constness. Since constness goes hand in hand with thread safety you really don’t want that violation.