std::move is just a cast operation. A better name might be std::cast_as_rvalue to force the overload that allows it to forward to move constructors/etc that intentionally "destroy" the argument (leave it in a moved-from state).
They don't destroy the argument - this is of course a big problem because the semantic programmers actually wanted (even when C++ 98 didn't have move and papers were proposing this new feature) was what C++ programmers now call "destructive move" ie the move Rust has. This is sometimes now portrayed as some sort of modern idea, but it actually was clearly what everybody wanted 15-20 years ago, it's just that C++ didn't deliver that.
What they go was this awful compromise, it's not destroyed, C++ promises that it will only finally be destroyed when the scope ends, and always then, so instead some "hollowed out" state is created which is some state (usually unspecified but predictable) in which it is safe to destroy it.
Creating the "hollowed out" new state for the moved-from object so that it can later be destroyed is not zero work, it's usually trivial, but given that we're not gaining any benefit by doing this work it's pure waste.
This constitutes one of several unavoidable performance leaks in modern C++. They're not huge, but they're a problem when you still have people who mistake C++ for a performance language rather than a language like COBOL focused intently on compatibility with piles of archaic legacy code.
Thanks for pointing this out. It's an absolute myth that C++ move semantics are due to backwards compatibility. The original paper on move semantics dating back 2002 explicitly mentions destructive move semantics by name:
It does bring up an issue involving how to handle destructive moves in a class hierarchy, and while that's an issue, it's a local issue that would need careful consideration only in a few corner cases as opposed to the move semantics we have today which sprinkle the potential for misuse all over the codebase.
I started a new project recently and chose C++ because I wanted cross platform, and a language that let me write the highest performance code I could imagine. C is so lacking in abstractions, I don't think I can deal with it. But C++ is such a pain, I keep looking at Rust and feeling temptation. I'm doing some number crunching, and geometric algorithms, among other things. Not sure if Rust is as good as C++ there.
I'm the wrong person to ask probably because for me Rust seemed like home almost immediately and that's not most people's reaction.
The brute optimisation for Rust is being done by LLVM, just like if you used Clang to compile C++, so your pure number crunching ought to be fine. If anything you may find it's easier to end up correctly expressing the thing you meant with good performance in Rust. If you rely on a C++ library of geometric algorithms, clearly "I can't find an equivalent in Rust" would be a showstopper and so it's worth stopping past crates.io to try a few searches for whatever keywords are in your head
Also, if you know that learning new stuff fogs up your process, you might not want to try to both learn Rust and work on this novel project simultaneously. Some people thrive pairing learning a language with a new project, others hate that and would rather pick, either do something old in a new language, or do something new in an existing one.
If you decide this isn't the right time but keep feeling a twinge, I encourage you to try it for something else, not everybody is going to like Rust, but it's a rare C++ programmer who spends serious time learning Rust and then decides there was nothing they valued from the experience -- particularly if you have no experience in an ML (F# or Ocaml are modern examples)
Thanks. I've learned a lot of languages and enjoy doing it, especially when much of it is a step up, so not a problem there. I may need to just dive in and try it out on a larger project. It was only after doing that with C++ where I really understood what I liked and what I didn't. A lot of the latter is the tooling/IDEs, which doesn't show up reading about the language. One thing I'm not sure about with Rust is porting a UI class hierarchy from C++. Base class `View`, sub classes `Button`, `VStack`, `TextField`, etc. I see how to replace virtual functions with a trait and impls for the various types. But for stuff (fields or methods) shared in the base class, this looks like one area where Rust is uglier than C++.
