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

It is very good to see that safety is actively discussed within C++ standardization committee. I hope "profile" brings tangible results in the near future. I do agree with Dr. Stroustrup's assessment that safety has to be dealt with within the context much broader than mere "memory safety."

The big issue here IMO isn't that the safe constructs don't exist. It's that many of them look identical to the unsafe ones, so the unsafe ones "blend in". `x[i]` is safe on a span, but not on a raw pointer, but they look the same. IMO it would be good to have a flag that changes the syntax of raw pointers (casts, and other unsafe constructs) to be more explicit and verbose. E.g. in this mode, `int *x` gets spelled `std::unsafe_pointer x`, with no more `&` or `[]` operator, instead forcing you to write `x.unsafe_deref()`, `x.unsafe_subcript(i)`, etc.

Great talk. The don is making the argument for functional C++, with room for critical exceptions and I love it. Though I know it's not enough for a lot of people/use cases. Profiles sound like a great way to offer the guarantees people need, without breaking compatibility or limiting the engineers freedom of expression. I hope people can give it unbiased look.

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.

The example at 50:37 is something I ran into once, had to loop over a vector and add elements to it during the loop. Compiling with -fsanitize=address helped me catch this. The only safe way to do that was to use a c-style size_t index and index the vector with .at(). A perfect example why for-each C++ loops can be dangerous sometimes.

Great talk. What I really miss in C++ is safety when it comes to numeric stuff. Physical Dimension and unit handling should be part of the standard library. Further we need an abstract numerical type, which allows to specify a required or guaranteed inclusive and/ or exclusive range and resolution. Numeric under- and overflows would then, in a chooseable way, be saturated or require to be handled explicitly.

he's absolutely correct that safety is not just type safety and security is not just memory safety, also completely irrelevant, the compiler and tooling should help on what is possible helping

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.

Well, I'm glad it's recognized that simply blaming the programmer isn't going to cut it, ref "enforce guidelines". We've had 30 years worth of experience with "get gud". Clearly, it doesn't cut it. Safety must be enforced (at the very least in scenarios where safety is paramount).

Legend!

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

Please, ABI break! We need it!!!!!!!!!🧡🦊

Bjarne looking really good!

Most awaited!! 😃

The only way to make c++ safe is to drop support for unsafe options (most of c). People will always use every option they are given and sometimes even in incredibly creative ways. At some point you need to truncate early constructs. Maybe it’s time to change the name of the next generation of c++ to be clear.

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

I always look forward to these keynotes. Thank you for sharing Bjarne, great material as always.

I understand "C/C++" to abbreviate "C and C++". I wouldn't say a single project is written in C/C++ (except when it uses both languages), but I would say that I am able to write C/C++.

Template strong types can help find bugs, but matching it up to a large amount of older code requires a lot of casts. The strong type template class I threw together also checks for numbers outside of the expected sizes and this can check for overflows when in debug builds. The template could also prevent overflows in the release build. The one problem I have though is that a strong type template can't have a constructor and still "drop in" to the existing serialization code. So any code that creates a type has to declare it and then set it's value. Going back it would have been better to have a strong alias option.

these 89 minutes better be worth it. edit: that was a short 8 slides. i'll come back to C++ when someone from the committee decides to get up to date on PL theory.

I'm curious about the security concerns laid out here. The analogy with the nicer car still applies. If there is a more appealing target, C and C++ are both easier cars to break into than languages with runtimes. Appealing might mean might be easier to steal and sell, and/or easier to break into. No language or library offers complete safety, what is empirically shown is that software attacks are way more appealing than physical attacks to carry on a consistent basis. To rephrase my concern about the arguments done in that sense, there's a difference between bugs caused by lack of tooling (or tribal knowledge about it) to prevent issues that should be prevented at language level or built-in. There's also a difference in how you can cover your tracks and risks involved, when committing malicious actions physically, and committing them remotely. I'm not saying physical world security risks don't exist, just that convenience that of exploiting the software ones make them a more appealing approach regardless.

Good morning, C++ is really an awesome language, i like specially the documented and public development, the draft specs, so on, that's universally how great projects really get to exist apparently. Regards Jean-François

why are these videos not listed ?

TIOBE is by no means an accurate measure of popularity.

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.

Left Rust out of the list of memory safe languages.

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 :)

@1:16:10 I'm confused. an immutable sting is just a const std::string, no? what's the deal?

🎯 Key points for quick navigation: 00:10 *🛡️ Overview of C++ Safety* - Bjarne Stroustrup introduces the concept of writing safe C++ code. - Defines safety, discusses the need for safety, and highlights the importance of addressing safety issues. 02:08 *⚙️ Techniques for Writing Safe C++* - Emphasizes the necessity of judicious programming techniques for ensuring safety. - Discusses the importance of type and resource safety, memory safety, and guidelines for safe coding practices. 07:04 *🌐 Challenges in Ensuring Safety in C++* - Explores the challenges in making C++ safer while serving a wide range of uses. - Discusses the difficulties in upgrading developers and the importance of convincing the community to prioritize safety. 10:24 *🔒 Safety Beyond Type Safety* - Highlights different types of errors beyond type safety, including logic, concurrency, memory corruption, timing errors, and resource allocation unpredictability. - Emphasizes the significance of addressing various types of errors for overall system safety. 14:24 *🔐 Distinguishing Safety from Security* - Discusses the distinction between safety and security in programming. - Highlights various security threats and vulnerabilities that are not directly related to type and memory safety in code. 20:39 *🔄 Evolution of Language for Safety* - Traces the evolution of the C++ language regarding safety features, including type checking, overloading, interfaces, and inheritance. - Discusses the advancements such as templates, Concepts, containers, algorithms, and smart pointers for enhancing safety in code. 27:48 *🧰 C++ Principles and Best Practices* - Importance of no implicit violations of the static type system - Avoiding raw pointers and using higher-level abstractions - The benefits of using C++ features for safety and productivity 31:56 *🚧 Formalizing Safe C++ Practices* - Need to formalize rules for safe C++ use - Providing ways to verify code functionality - Enforcing guidelines for safe coding practices 35:15 *🛡️ Simplifying Code for Static Analysis* - Using static analysis to eliminate errors - Rules to simplify code for efficient analysis - Providing libraries and abstractions for safe coding 42:57 *🔄 Handling Resource Management* - Avoiding resource leaks with unique and shared pointers - Prioritizing local objects to minimize allocations - Understanding the limitations of smart pointers in some scenarios 46:01 *🎯 Eliminating Dangling Pointers* - Dangers of dangling pointers and their impact on code - Enforcing rules to prevent the use of dangling pointers - Ensuring every object has a single owner for proper resource management 55:46 *🧩 Evolution of C++* - Arguments surrounding safety in C++ - Mention of the need for unsafe constructs and interoperability with other languages - Discussion on the cost and challenges of converting large systems to a new language 01:00:13 *🔒 Cost Analysis of Converting Systems* - Estimation of costs involved in converting a 10 million line system to a new language - Consideration of developer salaries, building costs, and outsourcing implications - Discussion on the challenges and complexities inherent in such a conversion process 01:04:08 *🖥️ Ensuring Safety with Standard C++ Code* - Importance of fundamental guarantees such as type and resource safety in C++ - Proposal for gradual conversion with supported guarantees - Need for open set of guarantees and standardized safety measures for memory, range, and arithmetic safety 01:06:14 *🔐 Type and Resource Safety in C++* - Definition and significance of type and resource safety in C++ - Discussion on the challenges of maintaining mutable versus immutable data - Emphasis on the need for coherent arguments to support design choices in C++ 01:17:12 *🛠️ Integrating Safety Measures into Toolchains* - Challenges associated with integrating new tooling and static analyzers into C++ projects - Encouragement for the development of static analyzers that support specific profiles - Utilization of compiler capabilities for static analysis in C++ development practices 01:24:16 *📚 Libraries and Pointers Safety* - Annotating import or include statements with assumptions can improve safety when dealing with C++ libraries. - Handling subset and disjoint libraries can be too complex to mechanically deal with, requiring human understanding. - The problem of mixing profiles in libraries passing pointers may persist for decades, necessitating efforts to manage rather than eliminate it. 01:25:41 *🧰 Benefits and Challenges of Using Concepts* - Proper use of Concepts in C++ can simplify code and improve maintainability in specific domains like communication software. - Avoid using low-level guarantees in requires clauses, as it can lead to confusion and complexity. - Design Concepts to encourage composition by making them high-level enough to be widely applicable in various algorithms.

This is a really good summary of the safety features built into Rust and enabled by default. I hope that Bjarne is looking at the hard work being done by the Rust community as a path forwards for a safer C++ instead of ignoring it. Refusing to name Rust in this talk is an interesting choice, especially removing it from the list of languages in that NSA quote 😉

So wich is safest c++ compiler i can work??

Fabulous presentation - I have just managed to get a legacy code base compiled as C++20... Some of the code (UI) dates back to the early 90s and is based around MFC which relied on being able to pass a string literal to an api expecting a LPCSTR (wtf??) - this was a real P.I.T.A. to workaround but the code is working. At least the new stuff can now be developed using modern techniques.

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 ))

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

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.

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.

C/C++ is the only reference to C++ I see in job adverts for embedded C++ here in the UK. It is a real turn off for me but I'm getting more resilient! I often ask which standard of C++ they work to and the majority of responses I get are; we actually only use C, or C++11. In the UK at least C++ is still really struggling in the embedded world and it's not hard to see why with all the heap allocation, huge cost of importing a header (looking at you iostream) and the cost of not forcing exceptions off. Memory is still incredibly precious and limited in my world. Very encouraged to see Bjarne banging the drum for us embedded folks. Maybe with a bit of focus we can get the embedded world off of C++11/14/17 within the next 20 years!

"If you're writing C-style code you should be horrified" Better: If you want to write C-style code, do it in C.

A lot of Rust enjoyers don't listen to the talk and think he is just trying to to make programmers better not the language. He is directly addressing the point of memory safety arguments against C++, he says it's not enough to be just careful, it's not enough to have a core guideline. He wants C++ to be safe by default and it be enforced just like Rust, but he also addresses safety isn't just memory safety it's more, so Rust also has unsafe parts aside from memory safety. He is trying the evolution approach, making C++ safer in a more pragmatic way. But it is more challenging and takes a lot of time to get it right. Mostly because of backwards compatibility. No, Rust also has some parts that can't be changed because of backwards compatibility, being a new language is flashy, same for the time when C++ was invented. But it's really in the long term we will know which animals go extinct. Overall I think it is great that Rust started getting attention to memory safety, more competition and ideas on how to code better is great. And I would love to see how C++ handles this in the future.

the amount of logical fallacies and rhetoric figures in this talk are astonishing. I learned programming with C++ and I am sad to see what has become of it.

Much of modern C++ development is in reaction to developments in other languages as it should be. In this case Rust seems to have seeped into the language developers minds. I guess the old C++ philosophy of trust the programmer is history.

500k/year to write 5 lines a day? It better be some insane code.

Engineer the software to extract good behaviors from users. C/C++ relies on IMPLICIT assumptions which inevitably expect that users will do the right thing. Rust recasts assumptions as rules and enforces them EXPLICITLY.

"you can't break billions of lines of existing code" and this is where we disagree. The people compiling 80 year old programs that will break aren't using gcc 13 or any version of clang. This idea that if we make a breaking change to c++ people with legacy codebases will abandon C++ is dog shit. If people are abandoning C++ for newer languages, do you really think their primary concern is backwards compatibility? Newsflash, *rust* _isn't_ backwards compatible with c++ code, yet people doing embedded development are flocking to rust over c++. WHY? The answer is _because they want to opt into the newer features that C++ isn't providing_ because we insist on backwards compatibility.

>>We are talking about it because the U.S. gov talks about it. And if we didn't, someone else will tell us what to do.

This is video about C++ and constructive criticism is welcome, however Rust users complain non-stop about being ignored under so many C++ topics. There are many other languages which are ignored too and yet, I haven't seen such toxicity.

How about delive packet manager?

It’s funny how he never mentions rust as an alternate language

Also the NSA document cites another more or less well known language: "Examples of memory safe language include C#, Go, Java®, Ruby™, Rust®, and Swift®."

47:51 Thank you for finally explaining Rust lifetimes to me!

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

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!

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.

One thing that frustrates me with listening to Bjarne talks is all his "Yeah, we solved all these safety-problems back in the eighties. See this slogan I wrote down at the time? We just never got around to implementing them.". I do not care about how fantastic your crystal ball is if all you're going to do is to save all the wisdoms for a bunch of presentations several decades later.

Long live Bjarne! The voice of common sense. True genius of our generation. Every major success in software business is written fully or partially in C++. I mean what are we talking about? C++ to dissapear? To be replaced by Rust or other? Maybe it will eventually happen in 50-70 years or so. When AI learns to program it will program safe C++ because we will tell it to do so. Bjarne is activelly building the foundation for future - by adopting C++ for new generation. Thank you Bjarne!

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.

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

28:21 so this is how to open file

Lol @27:02 ! At first I thought he was making a point by trying to see who in the audience would be tricked. That was before I realized, not only did the audience not see the problem, he didn't either.

No language is 100% safe, but we shouldn't confuse small sections of code marked unsafe and an entire language that is unsafe. I feel that is a false dichotomy that has directed many towards apathy when it comes to improving language safety.

wait, at 45:09 is he suggesting embedded people prefer heap to stack? lol. If variable size is an issue, they would change it so that it live in the data sections, aka global. Managing the heap is very costly and wasteful if you are in such constrained environment.

he talk about language evolution to better safetu, but it still provide unsigned division on (signed/unsigned). Multiplication produces result of same size as arguments. And looks C/C++ newer change this behaviour. That`s essence of c++ safety.

“use rust” - those are fighting words

Overview video. No details here.

I'm curious about the guideline for safely using std::move. It makes the original object invalid and will cause run time error

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.

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

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.... 🙄

"Safety is not just memory safety". Right, probably why other, safer languages don't restrict themselves to memory safety either. Welcome to the safety club! (memory corruption is still the top issue).

I don't understand the cult of stability. C++ has standards which are compiler swtiches, so I don't understand why a standard wouldn't allow itself to break backward compatibility for the purpose of changing things to be safe by default instead of by best practices.

C++ just need one things : an effective one element vector , not mor

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

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

The standards committee Chair seems so smart and in touch with the issues, and then you have… this guy. He needs to get out of the way and let people who still have their mental faculties lead the way before he stains his legacy even worse. What a discredit to our entire industry. It’s embarrassing.

The unsafe programmer is ubiquitous now, so programming languages got new responsibilities..

Great talk Bjarne. Perfect overview of the direction towards a safer modern C++. I hope that this talk reaches the confused crowds with a distorted understanding of programming language safety., especially the non-expert programmers who are adversely influenced by overly enthusiastic Rust advocates. Key takeaway: LANGUAGES ARE NOT SAFE.

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.

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

This lecture is a massive middle finger up to the NSA and the White House.

So the idea is to build a set of new abstractions and then only use those? And the rest is all there, but we shouldnt use it.

I always take caution if someone want to use RAII, cause RAII objects have one critical issue, THEY DONT RELESE RESOURCES IN VISIBLE WAY 28:25 is perfect example, so how anyone can know is File_handler is relesed or not, if there is no relese call visible

I don't agree with the statement that low level stuff is offloaded by safe languages to C/C++. This simply isn't true. They offload to C, then C might then call to C++ but in almost all cases they go to a C interface because C++ just isn't interoperable with any other language. It isn't a problem with the safe languages, its a problem with C++.

If he consideres 10MLOC a "medium-sized" project I now understand why C++ (as well as many other programming languages and enviroments) are so hopelessly overengineered and overcompilicated. Most programming projects are actually comparatively small. People don't use python because it's "simple", they use it because creating a small project doesn't require lots of ceremony, just code and run. No good reason why C++ compilers could not support an uncomplicated compilation mode as well.

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

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.

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.

Why is this a talk from 2023 and not 2003? C++ had it coming for a long time and people will finally turn their backs. Good for everyone I'd say.

std::safe vs rust’s “unsafe” let people opt-in, if it works - it will dominate

Isn't he the one who made "C++"

Just use rust lol

undefined behavior is a bad feature of the language

“A lot of the so-called ‘safe’ languages outsource all the low-level stuff to C or C++,” Shots fired.

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

I have to turn Bjarne down until I can barely hear him so I'm not deafened by his whistle.

With all due respect to the massive achievements of Mr. Stroustrup, but this talk feels quite desperate to me. He doesn't even bring himself to say the word "Rust", either out of fear that the mere mention of it might speed the decline of C++, or because he feels that it is beneath him. Instead he constructs a straw man by mentioning how focusing on memory safety alone isn't enough, and that C++ will cover that and more in the future. Don't get me wrong, I am not out to bash C++. In fact it is still my daily work horse, but I think Mr. Stroustrup is in denial about C++'s future. I mean, just look at slides 71 and 72. If this is his plan to save C++, I think he'll need all the luck he can get.

Dear Bjarne; - You could have made the presentation more organized, legible and the code formatted. This perhaps shows why C++'s tools are lagging behind. - It’s not a valid defense mechanism: “There are so many codebases written in C++ and swapping cost is 1B dollar for 10M lines of code. So please stick with C++" 🤔 - You should improve the working speed and voting mechanism of the standardization committee. - You should make better and updated official website(s) for learning C++ if you want to attract the new generation. - Finally you should break the backward compatibility if you REALLY WANT to "Safe, Clean and Uncomplicated C++".

"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.

2000 LOC per year is the point where Bjarne lost me. Why even deliver these talks if all you can muster is defensive BS?