Delivering Safe C++ - Bjarne Stroustrup - CppCon 2023

Dr. Stroustrup is selling a snake-oil cure, for a disease he created, and which he continues to promote.

I never thought I would code in C++. I never thought I would code, for sure not games and especially not with C++. And here I am...And now I am thinking of how many things I could do and learn instead of this endless fighting with compiler and waiting for compilation to finish ))

To be honest, I am disappointed by this talk. It is time for C++ to break backward compatibility to clean up the language. Yes, there is legacy code. But it should not be used as an excuse not to do the right thing.

That train has already departed. There is a new king in town: R U S T

Why there so many conf and presentations about c++ and YET problems still there!?
Just, lets get used with amount of stuff and beutiful techniques you proposed! Please, give us time before the next release!

So basically C++ is a hostage of old code

Left Rust out of the list of memory safe languages.

std::safe vs rust’s “unsafe”

let people opt-in, if it works - it will dominate

Going from any language to another sounds like a biased decision without sufficient data.

That File_handle example just seems crazy to me. You have to jump through so many hoops to properly catch/handle errors. I just want to open a file, and get an error code when it fails. To do that you've got to create an exception type and throw it in your ctor...if you dont handle that exception thr compiler doesnt warn/tell you, and to catch the exception you have to introduce a new try/catch scope at the call site, make sure the exception type matches (compiler wont tell you if its wrong). Then you have the awkward situation of assigning the resulting file object outside the try/catch scope, or putting the rest of your code inside it and risk making the source of your exceptions ambiguous and seperating the handling code from the line that caused it. Handling errors should be easy and the default...C++ makes it so unnecessarily complicated. It makes sense why Bjournes example didn't include handling the error :)

undefined behavior is a bad feature of the language

I don't really get all this "safety" focus. Personally I'm very cautious about pointers, but I get that everyone might say the same thing, so I use smart pointers, RAII etc. I think this just solves 95% of safety issues in C++. So the next step is to enforce "profiles", which basically mark regions of code like safe and unsafe, just like the "unsafe" keyword does in Rust. Ok fine with all of this, I think there are much more urgent things that C++ needs to keep going forwards, and these are QoL issues:
- short arithmetic types as a core language feature. It is insane that I have to type std::uint64_t to declare a number variable.
- const by default, at least as a compiler option. I think that 40% of my codebase is the "const" keyword
- arrow style lamdas, because while ranges improve things a lot, it is still a pain to have to write a full lambda with capture, brackets and return when I need just a single return statment with an empty capture
- variant and tuple as a core language feature, because again, they're used over and over, and the state they're now is just so verbose for something so simple
This might seem just syntactic sugar, but it isn't. It improves readability, mantainability and let the programmer focus for on the problems they're trying to solve. Safety is a problem, sure, but as also Bjarne said, no language is totally safe, and I don't think that it is "safety" that keeps C++ from moving forward.

It’s impossible to have a meaningful conversation about this topic in context of the Rust acolytes who show up to brigade this topic every single time. An immune system is required.

No one was laughing at his jokes, poor Bjarne :(

I'm going to design a language that I will call "Cex", just so that you can have "Safe Cex".

I am a bit disappointed that C++ is going to be more complicated, instead of simplified. Compatibility to old code is a burden preventing C++ to more forward elegantly.
If C++ cannot be simplified. It will die or become dinosaur. When the generation who learnt programming when C++ was popular passed away, it will die, because new generation prefers simpler languages.
Herb Sutter's work is more inspiring.

I am disappointed actually. I love and hate c++ both its efficiency and complexity. And I don't get it why we will not create cpp 2 or something like that. There is an successful example in front of us, python. they announced that they would kill python 2. why we don't do that? why we don't say the industry that you have 10-15 years for c++23 and we just release patches. you have 10-15 years to switch from cpp to cppv2. if we will concern the ten of million of code every time, than we just will stick in past and cpp will go more and more complex so that no one will fully understand the language anymore.

It seems as though the development of C++ has got out of hand. How else can you explain that even with several new standards coming out over the last decade there are still these kinds of issues with C++. Also see Dave Abrahams talk about reference un-safety (the conclusion being switch to Rust). Trying to save C++ by having developers learn the CppCoreGuidelines, and 20 thousand line document, just seems very unlikely. It's amazing that C++ still has the Tiobe ranking that it has (why aren't people moving on?). Thank you for everything, Bjarne. Now is the time to let it go, really.

Just use rust lol

Oh man. I wish they had a language with affine types. That way you could have memory safety without a garbage collector.

Unpopular opinion: this is yet another very generic, too spread out speech equivalent to what a famous Eastern-European football player/star once said, i.e. "we must do well, such that we don't do badly".

BTW, what about RUST, the already not-so-young C++ replacement with built-in-safety mechanisms, which are advertised as 0 overhead (compile-time overhead only), which should also allow people do anything they can do (i.e. hardware-level interactions) in either C or C++. What is Bjarne's take on this? Is he defending C++ because of the non-negligible legacy code that one cannot simply port it to a language that addresses all those issues he presented in his agenda of "how can you help"? Because with any product or idea, it is completely fine to admit that there is a critical mass it can reach, beyond which its only future is graceful sunsetting. I, myself, identified as a C++ fan, but I have learned to not get overly-attached to tools, rather solve problems gracefully.

Thanks a lot and respect, Bjarne! Simple rules to avoid safety issues, as earlier said Bjarne: use standard libraries and write good code!

Too little too late... And not by a small margin. Anybody could see 10 years ago that without breaking changes C++ is dead end wrt safety.

Swift is my choice for new projects, and pure C for old projects!

I think if Bjarne, as the architect of C++, saying "there is no need to panic" in response to criticisms about C++'s safety, then it is time to concern for C++ folks. And he appears to be gaslighting as he didn't mention Rust given the fact Rust is the biggest competitor of C++

"If you're writing C-style code you should be horrified"

Better:
If you want to write C-style code, do it in C.

I'm a bit (not just a bit actually) disappointed that Bjarne did not explicitly address Herb Sutter's ambitious project CppFront. The guy is doing the lord's work, amplified the whole safety & security issue, wrote a custom compiler to backup his vision, seems to be largely supported by the community, yet not a mention.

Nice talk, thank you for that. I guess in the end it comes down to the programmers. Learn your language (in this case modern C++) and your tools. Another language won’t solve problems and in a lot cases C or C++ is underneath anyway (Python, JavaScript, etc.). Let’s keep improving, it’s like building houses, humans don’t build houses like they did 20 years ago

The reason C++ is relatively unsafe is not because the language lacks constructs, but because of the complexity of the language itself. What makes a program safe is not the language, but ultimately people. As the language becomes more complex, mistake and unsafeness happen, and when that happens, effective~ books containing hundreds of guidelines come out.. Just for one language. In the future, C++ will be the language for AI that can memorize the language's countless, preferably well-known, rules.

Some people say that there is no need to know the ins and outs of the complex rules of the C++ language, but the reality is not so. Development is not done with toys, and companies want to know the complex rules of the C++ language when recruiting new employees. This is because people who do not do so will not be able to communicate smoothly during C++ work. The committee appears to be trying hard to ignore this fact.

Loads of: yes, you can write safe C++ code, but of course you need to know this part of C++, and that means you need to know that part of C++, and some other parts too. Plus you need external tooling. C++ was nowhere near mature in 1979 btw, that's why Apple went with Objective-C in the 80s. That type safe linking is still not perfect in 2023 is.. I don't know.. I recently had to fix this in some code by a junior developer. All these years of development and still these state of the 1980's pitfalls.
It was a good idea to extend C, and RAII was a good idea, but to roll with these ideas in C++ you need years of study to master the rest of the language, and everything that resembles a rule in this language has exceptions.

To answer the writeonly question, one thing I can think of is a function taking an ouput parameter.
If the function parameter is marked as writeonly, then the caller can give a pointer to an uninitialized value.
And the callee must not read the pointed value. It must only write to it.

"obviously, you create a file handle class and its destructor closes the file"
No.
It is not that simple.
And that is why RAII is useless bullshit.
Why?
Because you must check the result of close/fclose function, because it can fail. And it is similar for many resources that you have to close.
And what can you do if it fails in your destructor?
You cannot throw an exception, because no exception should escape the destructor.
So you are f*cked. You are basically left with printing an error message or crash the entire program.
In the end, C without exceptions and a bunch of gotos is better at handling resources than RAII languages...

Why use a language where stack allocation is preferred over dynamic, when you could use a language where dynamic allocation is mandatory(!) After all, allocation never fails.... 🙄

Thank goodness C# never has an unhandled NullReferenceException which leaves the program running but with completely undefined behavior which could e.g. corrupt your database...

C++ allows me to compile pure trash. Rust does not allow naughty stuff to pass 😉

One profile feature I would really like is [[no_implicit_conversions]] e.g. the code must compile without any implicit conversion at all. Stronger check of typesafety

"C/C++" does exist a language as long as C++ must interop with C and maintain its legacy decisions from its beginning. You can't have C++ without C creeping in, unfortunately.

TIOBE is by no means an accurate measure of popularity.

Python and C++ - Winner Combination!

always got time for Bjarne - my book here on my des is by said from 1986 I was just reading it.

To use C++ correctly, you may need to read dozens of books and numerous guidelines.

Great talk full of wisdom and critical thinking, it is missed in these times of fads, easy slogans and sensationalist news in the world of technology.

Honestly a lot of the Rust folks here seem to have completely missed the point, that's kinda concerning, also I can kinda tell how fair your argument is actually being made by how likely you are to mention that "Bjarne left out Rust in that NSA list", if you say that, you never investigated what the NSA actually wrote because the first occurrence doesn't include Rust, only the second one does.

Nice to see Bjarne looking so healthy. He appears to be younger than 10 years ago.

Crap... I have his book edition from 2000, I have begun learning C++ with in October. Coming from MATLAB with some course work in Python also. Bjarne's presentations and Andrei's always make sense for new C++ users.