5 ms·

"How do I get to Dublin?" "Well I wouldn't start here" I've been a c++ dev for 30 years. I'll be retiring in a decade (or perhaps keep going), and I doubt I'l

"How do I get to Dublin?" "Well I wouldn't start here" I've been a c++ dev for 30 years. I'll be retiring in a decade (or perhaps keep going), and I doubt I'll ever see a 'safe' C++ in my working life. If the committee were even truly serious they'd adopt epoch releases and feature flags in the language spec (see Circle, doing it for real), starting in c++26, the next release. And adopting tooling as part of the standard like every other language. As usual, C++ is the outlier here. Then meaningful progress might start to be made in a measurable and testable way. Instead I'll read another dozen articles like this for next 5-10 years, and any talk of tooling or epochs will be kicked down the road for another few years as usual. But it's been a good lesson for all the other languages for better and worse.

tcbawo 3y ago
IMHO, Herb Sutter was spot on in his talk (https://youtu.be/fJvPBHErF2U https://youtu.be/fJvPBHErF2U) that it is impossible to walk back features of a language once they are in the wild. His cppfront is an interesting and refreshing approach. I think his “create a TypeScript for C++”, ie. generate safe, easy to understand, conforming C++ is the optimal path for where we are. Dealing with legacy codebases to evolve the language into something else is monumentally more difficult. And I tend to argue that maintaining legacy C++ systems with decades of features and bug fixes is okay for the right applications today.
- DrBazza 3y ago
  That's Hyrum's law, basically. With feature flags and epochs, it is possible to evolve C++ in the right direction with the minimum of friction and make it opt-in in a consistent fashion. Circle already proves this a feasible approach, and that's a one-man project. There's also clang tooling that modernizes old C++, and huge amounts of work on LSPs and the like for refactoring, so it is possible to provide tooling that mechanically fixes-up a large portion of old code.
  - Voultapher 3y ago
    As much as I appreciate the intentions of those working on the successor languages, they have invariably already sunk the ship before even setting sail in my opinion. They are already too fragmented, Carbon, Cppfront, Circle and probably more. By fragmenting they destroyed the only viable future I saw for them. If you want the goals of those languages, there is Rust today that gives you that and more. I'm not alone with that opinion, I know several people in the C++ standard committee that think this way. Even fluent interop is a race they are loosing.
    - DrBazza 3y ago
      My leading comment - "How do I get to Dublin?" "Well I wouldn't start here" All of the alternatives you (and I) mention - Carbon, Cppfront, Circle, aren't really fragmentation. They're all experiments at the moment, and all useful in testing out ideas in various different independent directions. The only comment I'll make about Rust, is that it's going to do a C++, and inspire another generation of languages (e.g. Hylo) that will takes lessons from it and improve - perhaps a nicer syntax, or better type inference and generics, or more formal proofs baked into the language. It's not an end-point. Can C++ be truly safe? I don't know, to me it seems totally at odds with where the language started, choices made and baked into the language, and where the very broad community and committee currently are.
      - Voultapher 3y ago
        I agree, Rust will certainly not be the end all language. The original language creator Graydon Hoare has interesting insights into what's next https://graydon2.dreamwidth.org/253769.html https://graydon2.dreamwidth.org/253769.html. Regarding successor languages, I fail to see how they are innovating though. Their sales pitch as far as I know, boils down to "Look Ma we have Rust at home". Which I don't find very compelling.
    - tcbawo 3y ago
      With cppfront, Sutter is explicitly not trying to create a successor language. His goal (like TypeScript to JavaScript) is to provide a complimentary, parallel language which provides complete forwards/backwards compatibility with C++. His hope is that (like TypeScript), the languages and communities evolve together. Any other technology that involves developing new tools, migrating code, or lacks completely frictionless interop will be inherently fragmentary. It reminds me of the classic XKCD comic: https://xkcd.com/927/ https://xkcd.com/927/
jandrewrogers 3y ago
In recent versions of C++, circa C++17 but especially C++20, it has become possible to build an alternative implementation of the language from within the C++ that makes a different set of guarantees and tradeoffs. This comes at a cost of no longer being able to use the standard library, particularly the vast legacy parts. This is how I expect the issue to be addressed because there is too much invested in backward compatibility. Some C++ development, usually around high-performance high-reliability systems, already operates this way to a significant extent, using an alternative re-spin of the language primitives from the ground up that make stricter guarantees and enable greater composability and verification. C++20 in particular makes a nice base for building this. You won't be able to force people to do things in a rigorous way, but providing a complete alternative goes a long way toward enabling safer code. I've seen alt standard C++ reduce bugs by an order of magnitude in real code bases (generally, since memory safety bugs are pretty rare in modern C++ in my experience).
- 8f2ab37a-ed6c 3y ago
  Any advice on how to write modern C++20 while avoiding all of the usual pitfalls, if that option is already available to C++ devs as of today? Is there a "C++ in 2024, the good parts" type of resource one could learn from?
- DrBazza 3y ago
  C++20 doesn't stop someone writing new/delete/malloc/free, or using pointer arithmetic. For me to be sure your code is 'safe', I'd have to audit it visually, and that's the worst of all worlds. The rigor can be put in the tooling, at the compiler level, as a flag. Then there's no 'forcing', it's just not possible to do certain things. Which is what is being advocated. Hoisting it a level further, to the build system, means downstream dependencies can (also) be compiled 'safely', or required to be safe, by default. Sticking a [[safe]] attribute into the language for regular source files would be a disaster. What's the point of one safe function in a library when the rest of it isn't safe? Having said all that, I don't disagree with anything you've written regarding idiomatic c++20 reducing safety issues, it's just that it's a problem that can be and should be addressed mechanically in the tooling. I'm just really, really, doubtful that C++ will ever get anywhere near 'safe' in the next decade, or, really, next couple of decades.

tcbawo 3y ago

IMHO, Herb Sutter was spot on in his talk (https://youtu.be/fJvPBHErF2U https://youtu.be/fJvPBHErF2U) that it is impossible to walk back features of a language once they are in the wild. His cppfront is an interesting and refreshing approach. I think his “create a TypeScript for C++”, ie. generate safe, easy to understand, conforming C++ is the optimal path for where we are. Dealing with legacy codebases to evolve the language into something else is monumentally more difficult. And I tend to argue that maintaining legacy C++ systems with decades of features and bug fixes is okay for the right applications today.

DrBazza 3y ago
That's Hyrum's law, basically. With feature flags and epochs, it is possible to evolve C++ in the right direction with the minimum of friction and make it opt-in in a consistent fashion. Circle already proves this a feasible approach, and that's a one-man project. There's also clang tooling that modernizes old C++, and huge amounts of work on LSPs and the like for refactoring, so it is possible to provide tooling that mechanically fixes-up a large portion of old code.
- Voultapher 3y ago
  As much as I appreciate the intentions of those working on the successor languages, they have invariably already sunk the ship before even setting sail in my opinion. They are already too fragmented, Carbon, Cppfront, Circle and probably more. By fragmenting they destroyed the only viable future I saw for them. If you want the goals of those languages, there is Rust today that gives you that and more. I'm not alone with that opinion, I know several people in the C++ standard committee that think this way. Even fluent interop is a race they are loosing.
  - DrBazza 3y ago
    My leading comment - "How do I get to Dublin?" "Well I wouldn't start here" All of the alternatives you (and I) mention - Carbon, Cppfront, Circle, aren't really fragmentation. They're all experiments at the moment, and all useful in testing out ideas in various different independent directions. The only comment I'll make about Rust, is that it's going to do a C++, and inspire another generation of languages (e.g. Hylo) that will takes lessons from it and improve - perhaps a nicer syntax, or better type inference and generics, or more formal proofs baked into the language. It's not an end-point. Can C++ be truly safe? I don't know, to me it seems totally at odds with where the language started, choices made and baked into the language, and where the very broad community and committee currently are.
    - Voultapher 3y ago
      I agree, Rust will certainly not be the end all language. The original language creator Graydon Hoare has interesting insights into what's next https://graydon2.dreamwidth.org/253769.html https://graydon2.dreamwidth.org/253769.html. Regarding successor languages, I fail to see how they are innovating though. Their sales pitch as far as I know, boils down to "Look Ma we have Rust at home". Which I don't find very compelling.
  - tcbawo 3y ago
    With cppfront, Sutter is explicitly not trying to create a successor language. His goal (like TypeScript to JavaScript) is to provide a complimentary, parallel language which provides complete forwards/backwards compatibility with C++. His hope is that (like TypeScript), the languages and communities evolve together. Any other technology that involves developing new tools, migrating code, or lacks completely frictionless interop will be inherently fragmentary. It reminds me of the classic XKCD comic: https://xkcd.com/927/ https://xkcd.com/927/

jandrewrogers 3y ago

In recent versions of C++, circa C++17 but especially C++20, it has become possible to build an alternative implementation of the language from within the C++ that makes a different set of guarantees and tradeoffs. This comes at a cost of no longer being able to use the standard library, particularly the vast legacy parts. This is how I expect the issue to be addressed because there is too much invested in backward compatibility. Some C++ development, usually around high-performance high-reliability systems, already operates this way to a significant extent, using an alternative re-spin of the language primitives from the ground up that make stricter guarantees and enable greater composability and verification. C++20 in particular makes a nice base for building this. You won't be able to force people to do things in a rigorous way, but providing a complete alternative goes a long way toward enabling safer code. I've seen alt standard C++ reduce bugs by an order of magnitude in real code bases (generally, since memory safety bugs are pretty rare in modern C++ in my experience).

8f2ab37a-ed6c 3y ago
Any advice on how to write modern C++20 while avoiding all of the usual pitfalls, if that option is already available to C++ devs as of today? Is there a "C++ in 2024, the good parts" type of resource one could learn from?
DrBazza 3y ago
C++20 doesn't stop someone writing new/delete/malloc/free, or using pointer arithmetic. For me to be sure your code is 'safe', I'd have to audit it visually, and that's the worst of all worlds. The rigor can be put in the tooling, at the compiler level, as a flag. Then there's no 'forcing', it's just not possible to do certain things. Which is what is being advocated. Hoisting it a level further, to the build system, means downstream dependencies can (also) be compiled 'safely', or required to be safe, by default. Sticking a [[safe]] attribute into the language for regular source files would be a disaster. What's the point of one safe function in a library when the rest of it isn't safe? Having said all that, I don't disagree with anything you've written regarding idiomatic c++20 reducing safety issues, it's just that it's a problem that can be and should be addressed mechanically in the tooling. I'm just really, really, doubtful that C++ will ever get anywhere near 'safe' in the next decade, or, really, next couple of decades.