3 ms·

I really wish they had found a less confusing way to bolt this move semantics / rvalue references stuff onto C++. It's an important addition, but I find myself

by ohazi 11y ago

I really wish they had found a less confusing way to bolt this move semantics / rvalue references stuff onto C++. It's an important addition, but I find myself having to do mental gymnastics every time I see code like this, whereas in Rust it just works.

nice_byte 11y ago
I agree with you. To be honest, it took me a few tries to understand how move semantics really works (the unfortunate naming of std::move really didn't help). I'm still not sure my understanding is 100% correct according to the standard, but at least my mental model makes sense to me and seems to agree with the behavior displayed by the compiler.
Animats 11y ago
The big difference is that in Rust, if you make an borrow error and try to use something you moved away, it's caught at compile time. In C++11, you dereference zero and crash, because the reference moved from was zeroed out.
jasode 11y ago
>I really wish they had found a less confusing way to bolt this move semantics / rvalue references stuff onto C++. There's some irreducible complexity with adding ownership semantics and the way standards committee ended up adding it to C++ is probably the most simplified way to accomplish it if you obey the constraint that the new compiler-assisted pointer ownership must coexist with legacy raw pointers and references. To me, the complexity lies in the 30 years of un-annotated raw pointers in existing C++ code that must not be broken or rewritten if new ownership-style pointers are bolted on to the language. I also think that another source of complexity/confusion is the label "move" in "std::move()". The word "move" is a verb and it seems to hint to beginners that some bytes changed position but unfortunately, that's not what's really happening. It might have been better to call it "std::rvalue()" -- the "rvalue" is a noun and you're telling the compiler that it is an "expiring value" that you promise to stop using. (Howard Hinnant[1] is the author of the std::move() C++ proposal and he gives good reasons why he called it "move" but I still think it's a confusing name.) >, whereas in Rust it just works. In C++, the defaults are "raw pointer" and unannotated references; the special cases are are unique_ptr, shared_ptr, &&, and std::move() In Rust, the default is explicit borrow pointers, and the special-case pointers are raw pointers inside unsafe blocks. Rust is "simpler" because it has the luxury of using a different baseline for its default case. C++ doesn't have that luxury. [1]http://stackoverflow.com/a/21358433 http://stackoverflow.com/a/21358433
- andrewflnr 11y ago
  I think most of us understand the historical pressure, but that's small comfort when we're neck-deep in arcane code. Indeed, for me it just leads to dark thoughts about the reign of Worse Is Better and how the good stuff rarely wins.
  - jasode 11y ago
    >I think most of us understand the historical pressure, It doesn't look that way from the GP's comment: "I really wish they had found a less confusing way to bolt this move semantics / rvalue references stuff onto C++ ..." ... is actually an example of not understanding (or not being aware of) historical pressure. If you create a new programming language (e.g. Rust) with a blank slate, you have more flexibility to make semantics "simpler" by rethinking the design of the syntax, the sigils, and the implicit defaults. Rust syntax accomplishes "move semantics" without double ampersands (&&) sigils and "std::move()".[1] The end result is that Rust syntax looks less cluttered to move ownership around. The key to Rust's clean syntax is the absence of "historical pressure". Rust starts from a blank slate without worrying about breaking legacy code. Rust wasn't invented in 1982. C++ move semantics uses C++1982/C++98 as a starting point and can't use naked variables to let the compiler carry out "moves". Legacy code would be ambiguous and compilation would break. The "rvalues std:move()" was proposed in 2002 and finalized for C++11. They had 9 years for others to challenge Howard's proposal and devise a simpler more elegant way that doesn't break existing code. Nobody came up with an alternative. Hence, the uglier C++ syntax bolted on for "moves" is probably as simple as we're going to get. [1]http://stackoverflow.com/questions/29490670/how-does-rust-provide-move-semantics http://stackoverflow.com/questions/29490670/how-does-rust-pr...

by ohazi 11y ago

nice_byte 11y ago

I agree with you. To be honest, it took me a few tries to understand how move semantics really works (the unfortunate naming of std::move really didn't help). I'm still not sure my understanding is 100% correct according to the standard, but at least my mental model makes sense to me and seems to agree with the behavior displayed by the compiler.

Animats 11y ago

The big difference is that in Rust, if you make an borrow error and try to use something you moved away, it's caught at compile time. In C++11, you dereference zero and crash, because the reference moved from was zeroed out.

jasode 11y ago

>I really wish they had found a less confusing way to bolt this move semantics / rvalue references stuff onto C++. There's some irreducible complexity with adding ownership semantics and the way standards committee ended up adding it to C++ is probably the most simplified way to accomplish it if you obey the constraint that the new compiler-assisted pointer ownership must coexist with legacy raw pointers and references. To me, the complexity lies in the 30 years of un-annotated raw pointers in existing C++ code that must not be broken or rewritten if new ownership-style pointers are bolted on to the language. I also think that another source of complexity/confusion is the label "move" in "std::move()". The word "move" is a verb and it seems to hint to beginners that some bytes changed position but unfortunately, that's not what's really happening. It might have been better to call it "std::rvalue()" -- the "rvalue" is a noun and you're telling the compiler that it is an "expiring value" that you promise to stop using. (Howard Hinnant[1] is the author of the std::move() C++ proposal and he gives good reasons why he called it "move" but I still think it's a confusing name.) >, whereas in Rust it just works. In C++, the defaults are "raw pointer" and unannotated references; the special cases are are unique_ptr, shared_ptr, &&, and std::move() In Rust, the default is explicit borrow pointers, and the special-case pointers are raw pointers inside unsafe blocks. Rust is "simpler" because it has the luxury of using a different baseline for its default case. C++ doesn't have that luxury. [1]http://stackoverflow.com/a/21358433 http://stackoverflow.com/a/21358433

andrewflnr 11y ago
I think most of us understand the historical pressure, but that's small comfort when we're neck-deep in arcane code. Indeed, for me it just leads to dark thoughts about the reign of Worse Is Better and how the good stuff rarely wins.
- jasode 11y ago
  >I think most of us understand the historical pressure, It doesn't look that way from the GP's comment: "I really wish they had found a less confusing way to bolt this move semantics / rvalue references stuff onto C++ ..." ... is actually an example of not understanding (or not being aware of) historical pressure. If you create a new programming language (e.g. Rust) with a blank slate, you have more flexibility to make semantics "simpler" by rethinking the design of the syntax, the sigils, and the implicit defaults. Rust syntax accomplishes "move semantics" without double ampersands (&&) sigils and "std::move()".[1] The end result is that Rust syntax looks less cluttered to move ownership around. The key to Rust's clean syntax is the absence of "historical pressure". Rust starts from a blank slate without worrying about breaking legacy code. Rust wasn't invented in 1982. C++ move semantics uses C++1982/C++98 as a starting point and can't use naked variables to let the compiler carry out "moves". Legacy code would be ambiguous and compilation would break. The "rvalues std:move()" was proposed in 2002 and finalized for C++11. They had 9 years for others to challenge Howard's proposal and devise a simpler more elegant way that doesn't break existing code. Nobody came up with an alternative. Hence, the uglier C++ syntax bolted on for "moves" is probably as simple as we're going to get. [1]http://stackoverflow.com/questions/29490670/how-does-rust-provide-move-semantics http://stackoverflow.com/questions/29490670/how-does-rust-pr...