3 ms·
> isn't even legit in modern C++. That's just move semantics. When you move it, it's gone at the old name. Exactly the opposite actually. Rust has destructive
by Calavar 1y ago
> isn't even legit in modern C++. That's just move semantics. When you move it, it's gone at the old name.
Exactly the opposite actually.
Rust has destructive move while modern C++ has nondestructive move.
So in Rust, an object is dead after you move out of it, and any further attempts to use it are a compiler diagnosed error. In contrast, a C++ object is remains alive after the move, and further use of it isn't forbidden by the language, although some or all uses might be forbidden by the specific user provided move function - you'll have to reference the documentation for that move function to find out.
This article explains the difference well: https://www.foonathan.net/2017/09/destructive-move/ https://www.foonathan.net/2017/09/destructive-move/
- ben-schaaf 1y agoIndeed, this is strictly worse than rust. The object is alive but in an invalid state, so using it is a bug but not one the compiler catches. In the worse case the move is only destructive for larger objects (like SSO), so your tests can pass and you've still got a bug.
- Aeolos 1y agoOr when you enable optimizations and since accessing an object with invalid state is UB, the compiler helpfully decides it is now permitted to format your hard drive. https://gcc.gnu.org/legacy-ml/gcc/2016-02/msg00381.html https://gcc.gnu.org/legacy-ml/gcc/2016-02/msg00381.html "The fact is, undefined compiler behavior is never a good idea. Not for serious projects."
- oconnor663 1y agoC++ teachers like Herb Sutter like to jump in here and make a correction: A moved-from object is in a valid state, you just might not know which state. You can still call methods on it that are valid in any state. ("What is your length?") But you shouldn't fall methods that are only valid in some states. ("Give me your first element.")