5 ms·
> This is why C++ code should use references more and pointers less. How's that working out in the era of move semantics? The point of move semantics is to ena
by nikbackm 11y ago
> This is why C++ code should use references more and pointers less. How's that working out in the era of move semantics?
The point of move semantics is to enable use of values instead of pointers. That's even better/safer than using references.
- catnaroek 11y agoUnfortunately, move semantics in C++ is broken, and will remain so until the type system finally understands that `std::move` is supposed to invalidate the original object. But, this being C++, I won't hold my breath.
- Animats 11y agoTrying to fix this with the type system doesn't really work. Tracking the changing attributes along a path of control flow with the type system requires an insanely complicated type system. Rust's borrow checker understands invalidation via move, and lots of other changes in variable state which occur along execution paths. That seems the way to go. But it has to be integrated into the language design. As a backwards compatible bolt-on to C++, it just won't work. (It's been tried. I tried once, about 10 years ago, and gave up. I talked to the designers of Rust, and they tried and gave up. There have been other attempts to get C++ ownership under compile time checking, and the result is either a new incompatible C++ variant or something that leaks like a sieve. Ownership needs to be a fundamental language concept independent of type)
- steveklabnik 11y agoHave you seen the Core Gudelines and the GSL? Not as powerful as Rust, but very interesting.
- catnaroek 11y agoThe C++ Core Guidelines aren't always mechanically enforceable. Experience shows that unenforceable rules will be broken. After all, what's undefined behavior, if not an unenforceable “don't do this” rule?
- steveklabnik 11y agoAlso, they don't deal with concurrency currently, either.
- catnaroek 11y agoI didn't mean to suggest this can be done with C++'s existing type system.
- ant6n 11y agoI thought moving will leave the original in some valid state. For example moving a vector may leave the original object as an empty vector. What's so broken about that?
- catnaroek 11y agoSometimes there is no valid state for a `std::move`d object, e.g. a `std::unique_ptr`.
- ant6n 11y agoWouldn't just be nullptr?
- catnaroek 11y agoThe very concept of a nullable pointer is problematic, because it means that every dereference operation is potentially unsafe. The only satisfactory solution is to enforce, using the type system, the rule that moved objects can't be reused. Unfortunately, C++'s type system can't express this.