4 ms·

Reminds me of point 3 in http://www.sebastiansylvan.com/post/language-design-deal-breakers/ http://www.sebastiansylvan.com/post/language-design-deal-bre...: “Yo

Reminds me of point 3 in http://www.sebastiansylvan.com/post/language-design-deal-breakers/ http://www.sebastiansylvan.com/post/language-design-deal-bre...: “You have to make sure that nullable pointers cannot be dereferenced. (...) Having every few statements potentially trigger a runtime crash is an expensive price to pay... for nothing!” [emphasis in the original] Once you have proper non-nullable pointer types, `static_cast` is a single pointer bump once again.

Animats 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? 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.
- catnaroek 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? 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. Wholeheartedly agree.
- hellofunk 11y ago
  No, he has said that "this" is a pointer because it was added to the language before references were added. This is covered in his FAQ.
- 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 ago
    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.
    - Animats 11y ago
      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)
      - steveklabnik 11y ago
        Have you seen the Core Gudelines and the GSL? Not as powerful as Rust, but very interesting.
        catnaroek 11y ago
        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?
- lomnakkus 11y ago
  > 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.)

Animats 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? 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.

catnaroek 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? 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. Wholeheartedly agree.
hellofunk 11y ago
No, he has said that "this" is a pointer because it was added to the language before references were added. This is covered in his FAQ.
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 ago
  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.
  - Animats 11y ago
    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)
    - steveklabnik 11y ago
      Have you seen the Core Gudelines and the GSL? Not as powerful as Rust, but very interesting.
      - catnaroek 11y ago
        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?
lomnakkus 11y ago
> 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.)