4 ms·
If you learn Rust or C++20, the marginal cost of learning the other should be trivial. After writing a bunch of Rust, I recently had to learn C++. I've been st
by Ericson2314 6y ago
If you learn Rust or C++20, the marginal cost of learning the other should be trivial.
After writing a bunch of Rust, I recently had to learn C++. I've been storing C++ in my brain as "Rust + delta of dubious ideas", which, not to start a flame war, has easily been a better compression algorithm for my brain than storing C++ in isolation.
For example:
- C++, const is part of the type. Clearly wrong.
- Rust, mut is property of variable, or & vs &mut. Correct, but lack of & with mut-polymorphism just causes needless suffering.
- Rust construction: good, Rust destruction: bad
- C++ destruction: bad, basically like Rust's. C++ construction: bad, matches C++ destruction.
(I've been saying for years that drop needs to consume, not borrow the thing to be destroyed, but no uptake :(.)
- vlovich123 6y agoWhat's the issue with Rust/C++ destruction? What do you mean by consume instead of borrow?
- Ericson2314 6y ago`drop(&mut self)` means, strictly going by the types I could call drop twice! We want an `&own` that is like C++'s rvalue references (so we can still drop DSTs) so we can have `drop(&own self)`. This correctly prevents one from calling Drop::drop twice without extra hacks, and demonstrates that the location is completely deinitialized and can be reinitialized to anything. It is also dual to how, seemingly magically, let x; x = foo(); works without Rust thinking there is an old value of `x` to get rid of.
- saghm 6y ago> `drop(&mut self)` means, strictly going by the types I could call drop twice! Wouldn't calling a destructor on an object twice will also compile in C++? I don't really see this as an issue in either language; the solution is "don't ever call `drop`/destructors manually"
- steveklabnik 6y agoTo be clear, it won't compile in Rust either; you cannot invoke Drop::drop yourself: fn main() { let mut v = vec![1, 2, 3]; v.drop(); } building: Compiling playground v0.0.1 (/playground) error[E0040]: explicit use of destructor method --> src/main.rs:4:7 | 4 | v.drop(); | ^^^^ | | | explicit destructor calls not allowed | help: consider using `drop` function: `drop(v)` error: aborting due to previous error std::mem::drop, which it refers to, does take by owner. Your parent's point is that this is kind of a weird corner case that only applies to drop.
- saghm 6y agoOh, interesting! I had never tried to call it manually, so I didn't realize that it wouldn't let me.
- gumby 6y ago> C++, const is part of the type. Clearly wrong. It’s pretty hard to express that an object must be invariant without a thing like that. You can’t do so with the storage itself as the object may be passed to a function.
- Ericson2314 6y agoBut if something is passed by value, the caller should never care whether the callee mutates its (shallow) copy. It's purely an unobervable implementation detail of the function.
- gumby 6y agoCall by value is not that common any more in C++ except with scalars. Although there are legit cases for what you describe, it’s a pretty uncommon case.
- Ericson2314 6y agoNot passing things around by value doesn't solve the problem. For example, template machinery has worry about absurd things like `const .. &&`.