2 ms·

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++ t

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.

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.