This is why C++ code should use references more and pointers less. How's that working out in the era of move semantics?
Bjarne has said that "this" should have been a reference; making it a pointer was a mistake. But the early design of constructors pointed the language in the wrong direction.
At least you can't assign to "this" any more. You can still assign to "*this", but probably shouldn't.
> This is why C++ code should use references more and pointers less. How's that working out in the era of move semantics?
Not terribly great. C++ references are neither move nor copy-assignable, which greatly limits their usefulness. For example, you can't use a reference as a loop counter. This means that references can never fully replace pointers: pointers are very natural loop counters when manipulating linked data structures.
What C++ needs is a movable, copyable, just non-nullable pointer type.
> Bjarne has said that "this" should have been a reference; making it a pointer was a mistake.
Unfortunately, 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.
Trying 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)
The 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?
I 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?
The 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.
> This is why C++ code should use references more and pointers less.
I'd agree except that using references leaves no hint at call sites that a reference is being passed. If you're using pointers, the pointer sigil (&) at call sites can serve as a really obvious signpost that something non-trivial is going on.
(This is really unfortunate, IMO, but there's no changing it at this point.)
Bjarne has said that "this" should have been a reference; making it a pointer was a mistake. But the early design of constructors pointed the language in the wrong direction.
At least you can't assign to "this" any more. You can still assign to "*this", but probably shouldn't.