Delivering Safe C++ - Bjarne Stroustrup - CppCon 2023

[@rreece90]

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

[@BrainTrance]

maybe he stopped programming

[@cafetechne]

Agreed.

[@soederwargestern]

maybe he stopped programming in C++. That certainly gives me white hair and a slight aneurysm @@BrainTrance

[@amomchilov]

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.

[@origamibulldoser1618]

Good observation about syntax obfuscating. Cpp2 may get you what you want if it actually happens. Unique_ptr is the default there from what I understand.

[@marco21274]

I would say that x[i] is mostly not needed. you can easily create sub spans now.

[@etherstrip]

That is a pretty cool idea. I might even try to push for something like this in our team (using clang-tidy for enforcement should be relatively easy)

[@franciscogerardohernandezr4788]

It´d be a bit like Rust, right?

[@von_nobody]

std::span `[]` is UB if you use index outside range. Correct example would be `std::map` where `[]` is safe.

[@sky_is_the_limit_13]

Love you Bjarne! Thanks for inventing this amazingly beautiful language!

[@testtest-qm7cj]

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

[@cafetechne]

The point is that the entire language was designed around type safety and security =/= safety. Our "leaders" are dumb careerists looking to use their government positions to land sweet sweet lobbying gigs. Garbage system.

[@cafetechne]

Type safety and bounds checking can only go so far if there is no proof based element at the core of a language, but that degrades efficiency--sort of the point of c++. Are these results related to Godelian incompleteness?

[@cafetechne]

clarification: Meaning, is there no such thing as a language without potential for the classes of issues we see today? Is that a result of the expressive limitations of symbolic thought?

[@Y2B123]

@@cafetechne I think it has more to do with the fact that there is no general way to definitively show whether a program meets the specification for all possible ranges of inputs, which is the halting problem. For trivial cases, you can manually prove its correctness and build upon those verified modules. Sometimes you incurr a cost for doing so.

[@bearwolffish]

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.

[@MaximBordyug.]

Awesome video by Bjarne as always.. Thanks for sharing...

[@torstenknodt6866]

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.

[@vikenemesh]

> Further we need an abstract numerical type, You are only creating new problems by building this into the programming language. Implement this in a library and then use said library, as is industry standard for many existing libraries handling for example BigIntegers or the like.

[@origamibulldoser1618]

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

[@keris3920]

"get gud" is still needed, even with language constructs that add safety rails. Even languages such as rust are not free from memory errors, and conversations around what causes these kinds of issues are still needed. We need both of these things to succeed

[@tashgordon]

@@keris3920as long as cpp has undefined behavior inherently specified or just lets the compiler vendors chose, the language is unsafe. No amount of good devs will mitigate this fundamental flaw with regards to safety

[@TheMohawkNinja]

@@tashgordon Yeah, but isn't a lot of that stuff mitigated by initializing variables at declaration, and a healthy dose of try/catch with ASSERT where necessary? Undefined behavior is more fundamental than programming, it's part of mathematics, so it seems like missing the forest for the trees to blame the language for that.

[@kwanarchive]

It was recognized a long time ago. Before C++11. That's why there's been constant improvement to language and tools. People just refuse to learn the tools, but would not think twice about learning a new language, which is just another tool. clang-tidy, clang-modernize, the guidelines library, and other linters. Address Sanitizer. Thread Sanitizer. Undefined Behaviour Sanitizer. You don't have to be a C++ expert. You just have to have a sense of intellectual honesty and professional responsibility to learn the tools that exist.

[@rt1517]

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.

[@tarasov9794]

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.

[@Phibred]

I agree, I hope that Herb has a presentation this year to show off its improvements. I worry that there might be some resentment for him going off and making such a radical change.

[@loogabarooga2812]

Neither sutters cppfront nor carbon are anywhere near "ready". A talk like this doesn't need to address these projects as impressive as they are.

[@simonfarre4907]

I suggest looking up Circle first instead. That's a "CppFront" that's been around for what, 7-8 years at this point.

[@superscatboy]

​@@Phibred Cppfront isn't a radical change though. That's kind of the point of it - it doesn't change C++ at all, radically or otherwise.

[@DataPastor]

@@loogabarooga2812 In a couple of weeks, Herb is supposed to publish cpp2 version 0.8, along with a permissive licence. Herb says the language is now pretty stable, there are very rare breaking changes. The labguage has actually ca. 160 contributors now, so it could already grab some serious atrention.

[@johnsmith9205]

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.

[@FalcoGer]

you can add to a different container and then merge the two. adding to a vector will invalidate the references, including your iterator in your range based loop.

[@binary132]

Const correctness goes such a long way

[@peregrin71]

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

[@SergePavlovsky]

such code would be very unpleasant to write and read

[@robervaldo4633]

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

[@BeffJezos69]

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

[@xamidi]

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

[@jonathanmarler5808]

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

[@antagonista8122]

Value construction (especially with intermediate mutation) was always nasty in C++, but since C++11 you can kinda unuglify it by using immediately invoked lambdas.

[@simonfarre4907]

Yeah, this is shy exceptions are terrible. 100% of the time. They are, dare I even say it, exceptionally terrible. std::expected is so much more reasonable as a concept (whether or not std::expected is implemented good is another question, irrelevant to my point). That way you are forced to deal with errors up front, and you don't get these weird lexical scopes/blocks that you mentioned. Exceptions will always, always be a nightmarish horror in my eyes.

[@darylfortney8081]

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.

[@JanVerny]

Watch the segment where he outlines what would be the financial and manpower costs of that. It's unrealistic to deprecate large subset of C++. Yet, the profiles enable you to selectively over time do exactly that. Sure it means devs have to opt in, but it's C++, there was never any other way.

[@karlsassie8403]

If you think C++23 is unsafe it’s a skill issue.

[@aacfox]

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

[@zactron1997]

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 😉

[@WitherBossEntity]

IIrc the NSA paper listed examples of safe language in two places, and one of them didn't include Rust. But yeah, I agree with you fully.

[@SergePavlovsky]

rust is a toy language compared to rest of the list, almost nobody uses it. even its creator didn't manage to rewrite their main product(firefox) in rust, and they had more than a decade to do it. so rust doesn't deserve a place on that list, it just produces too much unwarranted noise(just look at this comment section lol). even rust's compiler is written in c++(llvm).

[@IsaacKripke]

@@SergePavlovskyRust is shipping in the windows kernel right now, Android/ChromeOS/Fuchsia all have millions of lines of it, Linux is rolling out support for it, Discord/Cloudflare/Facebook/etc are using it for essential services, and the list goes on. It’s not a hobby language. Also, I doubt Mozilla ever intended to rewrite Firefox entirely in Rust, just as AT&T didn’t rewrite everything in C++. As for Rust using LLVM as it’s backend, I don’t really see the problem. C++ compilers literally compiled to C code for almost a decade after the introduction of the language. And as long as LLVM is generating the correct code there’s literally no point to duplicating it’s functionality.

[@PixelThorn]

Because even mouthing the first letter of Rust makes the fanboys come out the woodwork

[@hpesoj00]

Rust wasn't listed in the cited NSA document. Nice try though 👍

[@khatdubell]

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

[@junningli6506]

There is cost to rewrite old code, but the cost to develop in a painful way for all the future is even more costly. Why C++ cannot break with its past? Why?

[@valmirius]

This summary really shows the ivory tower syndrome the committee has away from its users

[@spell105]

What if I pull in a library written in C or older C++? An ABI break would be C++29 at the very least. Should C++20 become invalid now?

[@Therzok1]

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.

[@wjrasmussen666]

RUST

[@boccobadz]

@@wjrasmussen666 Still can't comprehend why anyone would choose rust over cpp for anything even remotely serious. I guess cpp coders like writing useful software instead of doing internet cult following.

[@LtdJorge]

@@boccobadzHave you ever written Rust?

[@aarholodian]

@@boccobadz While screaming "rewrite everything in rust!!!1" is a stupid notion, you've got to have brain damage or ego problems to claim that Rust isn't a substantial contribution to the industry just for the discussion on safety it opened alone. The implication that Rust is some obscure nobody language is likewise really stale, I really shouldn't be pointing out its adoption in the linux kernel, usage by Microsoft, Mozilla, etc.

[@TheMohawkNinja]

@@aarholodian Rust was encouraged by the U.S. government. That alone should make anyone hesitant to put anything with Rust code on their PC.

[@thomasziereis330]

why are these videos not listed ?

[@raymondhill7837]

TIOBE is by no means an accurate measure of popularity.

[@ino1729]

thats what he said in the talk.

[@FalcoGer]

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

[@SergePavlovsky]

when you have a reference to const std::string, some other code can have non-const references and can invalidate your iterators

[@fnizzelwhoop]

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.

[@valmirius]

Agreed, if they're not implemented and publicly accessible constructs then who cares if you solved them in theory or not?

[@sj71252]

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.

[@TheBusttheboss]

Skill issue

[@ryobg]

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.

[@memojl7195]

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

[@chrysalide_aero]

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

[@DrGreenGiant]

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!

[@JanVerny]

Meanwhile I failed an interview because the interviewer wanted my opinion on C++20 features and how I would use them. I didn't even know what C++20 looks like, cause at the time, at my job, we barely started with C++17 in our code.

[@Presskopp-i3m]

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

[@Altekameraden79]

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.

[@Hijazi-1info]

Because his book based on C++ 11 which considered modern

[@Hijazi-1info]

Cpp 11 is modern which his book based on

[@jamesarmes638]

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.

[@keris3920]

Likewise, it is disingenuous to call an entire language unsafe when safe constructs do exist in the language, although they are not explicitly marked. And it is also disingenuous to talk about unsafe as if it were small, which is certainly false when dealing with baremetal/embedded applications. That is no niche area either, as roughly 98% of all CPUs today run embedded software.

[@Omnifarious0]

​@@keris3920- The kind of disingenuous and obnoxious distortion of the capabilities of what many promoters of Rust see as the language they want to destroy is one reason I've become much less interested in Rust than I used to be.

[@dotnetforever]

@@keris3920especially when the entire language is unsafe. Every single cpp conf is about "what to do to not explode" please do not do this and do this..

[@LaserFur]

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.

[@dadlord689]

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

[@jesuscuadrado2291]

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.

[@blaze3495]

Bjarne looking really good!

[@brucerosner3547]

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.

[@znephf]

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

[@lesto12321]

on other news, a new salt mine have been discovered in the CppCon's basement

[@connemignonne]

It's crazy how he just edited Rust out of the list at 1:08 but kept all the others. Bjarne is specifically terrified of even mentioning Rust and this talk is desparate.

[@ryleitdept]

​​@@connemignonnei don't think so. There's no such thing as memory safe at all and no programming language is an excuse when it comes to memory safety.

[@AndreKostur]

@@connemignonne The quote he used is directly out of the NSA document at the bottom of page 5. Perhaps one should check the references before making accusations. Maybe you should be directing your accusations at the NSA for leaving Rust out of that list.

[@betareleasemusic]

@znephf Here is a link to the NSA document: media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF There is no mention of Rust there at all.

[@muzikleringucu]

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.

[@chololennon]

But you can't cite Python 2/3 as a successful example! it was a really big mistake (that serves as an example of what not do). Even Guido Van Rossum recognized it (kzbin.info/www/bejne/p3SYgaJtbMeZgas)

[@khatdubell]

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

[@julians.2597]

And be horrified.

[@v-for-victory]

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

[@tomkirbygreen]

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

[@ClaymorePT]

Python and C++ - Winner Combination!

[@junningli6506]

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.

[@musaran2]

It certainly hurt the syntax, because the simple(old) way is unsafe, and the safe(new) way is much more elaborate. Simplification without impoverishment is hard, but maybe it is time for a syntax reset by designing a near-transpilable cousin language.

[@ResZRyou]

I dont think so, cause many programming language still dependent to C++

[@chewey]

It doesn't seem likely it will die but it certainly seems like a lot of people have lost interest in contributing to it. There seemed to be years of excitement after C++11 that finally died with C++20.

[@igo9481]

C++ is never going anywhere

[@Arnob-vm4ub]

The main problem stopping cpp from advancing further is backwards compatiblity. A huge amount of very important legacy systems have been developed in it, so there's not much that can be done, which is why there are so many languages trying to replace it for modern non legacy projects.

[@KX36]

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

[@tusharsnx]

Most awaited!! 😃

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.

[@stulora3172]

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.

[@robervaldo4633]

I WTFd when he listed "security issues" almost completely unrelated to programming to dismiss memory safety

[@gjermund8053]

🤦🏻

[@maksimmuruev423]

How about delive packet manager?

[@markp8418]

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.

[@tusharsnx]

I think you might know already, but LPCSTR: long pointer constant string. which probably would be typedef'd to const char*

[@destiny_02]

LPCSTR is just Microsoft's way of saying const char*

[@yigitpolat]

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.

[@connemignonne]

All the things Bjarne says that he wants people to do in their C++ code are just things that are already enforced by default in Rust. He wouldn't need to spend so much effort trying to convince people to use RAII if it were just enforced by default. He even suggests that unsafe code should only live in blocks that are explicitly marked as such. Bjarne *does* explain the one reason why it's still important to keep working on C++ rather than swapping to another language in the section of the talk about the difficulties of moving to a new language. The reason is that a lot of stuff is already written in C++ and we're not about to rewrite some of these huge codebases, or reskill all of our C++ engineers to Rust, because this just economically makes no sense. Even if Rust is a strict improvement, people are still going to be writing C++ in 5 decades from now for the same reason that people are still maintaining COBOL codebases today.

[@connemignonne]

This "Languages are not safe! There is more to safety than just the rules enforced by Rust!" thing that you are saying here and that Bjarne has repeated on multiple occasions is obviously true but not at all a refutation of the suggestion that Rust is safer than C++. Nobody is saying your Rust code will be bug-free, we're just saying that there's a huge class of bugs that your Rust code structurally can't have that your C++ code can have, and that the way Rust forces you to write is just the way that Bjarne is trying to convince you to write anyway.

[@j3835]

"distorted understanding of programming language safety" -- meanwhile we had zero memory safety CVEs so far in Android's 1.5 million lines of Rust code. Someone is muddying the waters on what safety truly is, but I'm not convinced it's actually us Rust enthusiast. I'm pretty sure if you redefine it in *just* the right way we can get C++ to be safe too. :P Please, just stop with the misdirection. It's not useful to spend half of the talk defining what safety is, just so that you can say "but you know, Rust isn't actually really safe either!". It's not useful to continue putting your head in the sand and pretend that it's possible to write safe C++ at scale. It's not. What is useful however is trying to do something about it. I don't know if it will work, but I wish Bjarne luck with his profiles proposal, and I'd rather him go and try to make it happen, instead of constantly trying to muddy the waters so that C++ doesn't look bad.

[@MehmedUlusay]

Yes, there may be enthusiastic rust advocates but you seem chronic C++ advocate too. You should don't forget languages are tools, the aim is to produce safe and efficient software. People and companies now pragmatically choose the language which offers better tools, safety, references and ecosystem when starting a new project. Don't be a fanboy, compare the pros and cons.

[@MehmedUlusay]

​@@connemignonne Bjarne's calculation of the swapping cost at $1 billion was ridiculous :) A more technical and data-based comparison needs to be made. It is not a valid defense mechanism that there are many codebases written in C++. The presentation is not well worked out.

[@Ptr-NG]

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!

[@peterturchyn8685]

Left Rust out of the list of memory safe languages.

[@malborboss]

C++ devs butthurt hearing about Rust

[@anon1963]

​@@malborbossno it's just rusts terrible, toxic community

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.

[@user-iz2cygh56]

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!

[@cowprophet]

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.

[@NicolásMendoza-v8e]

Legend!

[@cafetechne]

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

[@criptych]

They could use more of those.

[@Phantom-lr6cs]

nsa and white house clowns go can and use whatver the heck they wish LOLZ they shouldn't put their nose's in our business

[@M69392]

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

[@cooperpilot8094]

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

[@Mobin92]

To be fair some of my best commits at work are actually negative LOC. Also adding a lot of code is easy. Fixing a problem by finding the exact location where it happens and just fixing that line, is hard.

[@davidjulitz7446]

Once I just changed one line and added another line of code after some days of debugging. But it was a several million-dollar fix. This bug hung around for >6 years or so and broke always the release build after some time running.

[@lesto12321]

@@Mobin92 and i would add the hard part of writing is having to learn new API, architecture the code, and if in legacy codebase, tippitap the change so the glass system does not fall apart. Porting an existing project you worked on to a different language is so much faster, especially if you dont risk to shoot your toes off every few change

[@Rexhunterj]

They are paying for experience in fixing problems, not in writing code. Code monkeys and problem solvers are two different breeds, anyone can write a mountain of code, it takes a specialist to find the root of the problem and solve it in a few lines of code.

[@yrds96]

@@Mobin92 jr commits: +200 -0 Mid commits: +500 -30 Senior commits: +100 -1000

[@websnarf]

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.

[@xavierdupont5772]

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

[@lesto12321]

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.

[@rigomatezoltan4302]

He does not elaborate it, but listen what he says at 12:25 , I think this implies that he would not just suggest to use the heap instead, but to rather have a proper system design about your memory usage.

[@kazbekdzhanibekov9154]

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

[@eyesopen6110]

Overview video. No details here.

[@ino1729]

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.

[@stefanpantos5955]

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

[@lesto12321]

It is also not true since another safe laguage is spreading into kernels and low level programming.. strange is never mentioned in the talk xD

[@SergePavlovsky]

c++ fully supports c interface, feel free to offload to c++ with c interface. there's no reason to do implementation in c when c++ is available.

[@SergePavlovsky]

@@lesto12321 how many additional decades that mythical safe language needs to replace c++ in its compiler(llvm) and in main product of its creator(firefox)?

[@MisterDevel]

Did any of you watch the talk?

[@ХузинТимур]

@@SergePavlovskyC code may be simpler than C++ and therefore have less bugs. Also, some features of C isn't supported in C++ (e.g. type punning or restricted pointers).

[@АлександрЛитягин-ф6у]

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.

[@RobBCactive]

In your "safe" example, what happens when you have a long series of multiplications? Your issue is you're wanting a cop out rather than learning how to deal with overflow that CPUs flag.

[@IamusTheFox]

I don't see any issue, could you please explain?

[@Spartan322]

@@roh_son Same, what?

[@zahash1045]

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

[@soniablanche5672]

funny way of spelling Typescript

[@mikeharry1799]

@@soniablanche5672 lol sure

[@thebasicmaterialsproject1892]

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

[@jbca]

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.

[@realjohanngoethe]

Ouch! That was a brutal takedown. Can you explain why? I'm genuinely curious.

[@MehmedUlusay]

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

[@lesto12321]

Also you cant make compatibility with C your strong horse for 30 years, then cry if people say C/C++. Like it or not, all the problem that C have are also in C++, even if they are discouraged.

[@SergePavlovsky]

why you don't want to use any of already existing languages without slow c++ standardization comittee and without backwards compatibility with c++?

[@b.c.34]

Back compactibility is really important for code sustenance and development

[@ekrem_dincel]

​@@SergePavlovskyConidering your aggresive replies here advise you to take a break.

[@junningli6506]

Agree. He still dismisses breaking the backward compatibility. I am very disappointed. As long as they linkable, it is fine to me.

[@Kor03d]

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

[@connemignonne]

Step 1. Write Rust instead

[@none_of_your_business]

i find it funny that he's just avoiding to say the word "rust" at all costs.

[@UnrealEngine_Master]

Step 2. Back to C++

[@wangyanzhao8475]

Step 2. Get fired

[@hannesw8436]

You guys need to get another hobby

[@IamJatin]

step 2 embed everything in unsafe { ... } when you want to do low level stuff

[@Avantarius]

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.

[@yldrmcs]

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

[@WilhelmDrake]

I don't think you know what gas-lighting is. Why do all Rust proponents seem like cultists?

[@Voltra_]

We mustn't have watched the same talk then

[@deathlife2414]

Rustlang users don't know thier simple app is depending on many component they forget they have become the npm of system programming. Having a size of 350 mb for simple mysql crud app. You can make any unsafe code in any language it is just rust makes it difficult.

[@criptych]

@@WilhelmDrake Because it's pretty much a cult.

[@budiardjo6610]

28:21 so this is how to open file

[@petr_e]

It's a shame to see that he uses const char* as a file path type.

[@robervaldo4633]

@@petr_e haha 😂

[@_daniel90]

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.

[@vytah]

Have you noticed the slide 4 at 1:08? The original NSA document says "Examples of memory safe language include C#, Go, Java®, Ruby™, Rust®, and Swift®." Guess what was changed.

[@PixelThorn]

Oh please, go read a book if you want drama

[@JohnDoe-vb3ks]

@@vytah nothing. There's two places where NSA list memory safe language in there report. One on page 3 and other on page 5. p.3 These inherent language features protect the programmer from introducing memory management mistakes unintentionally. Examples of memory safe language include C#, Go, Java®, Ruby™, Rust®, and Swift®. p.5 NSA advises organizations to consider making a strategic shift from programming languages that provide little or no inherent memory protection, such as C/C++, to a memory safe language when possible. Some examples of memory safe languages are C#, Go, Java, Ruby™, and Swift®. You know, it's not hard to find original document on the internet, and check.

[@MartinGeisler]

@@vytah This is only partly correct as there are two places in media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF where the languages are mentioned: page 3 and 5. The text on page 5 says "Some examples of memory safe languages are C#, Go, Java, Ruby™, and Swift®."

[@Spartan322]

@@vytah The NSA has two different lists in that, page 5 doesn't list Rust, how about you actually check things before you make accusations.

[@nailbomb420]

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

[@troyhamilton1889]

“use rust” - those are fighting words

[@coding_with_thomas]

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

[@clementdato6328]

No it’s not down to programmers. The wrongest take in the safety problem. At scale, programmers can be first order approximated by an average programmer.

[@robervaldo4633]

here's a quote from Brian Kernigham: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

[@CuriousCauliflowerX]

Same old from Bjarne: fighting windmills, redirecting blame and never acknowledging the new state of the art. Rust is the new state of the art, the securty community wants you to do as good, not to pontificate definitions of safety and how to shift the blame on language users.

[@M69392]

In fairness "Profiles" seem like the right idea. But yeah, patronizing when you're late and (maybe) catching up does not give a good impression.

[@IamusTheFox]

Question, it's a c++ talk is it not?

[@Raymanujan]

OG GOAT

[@earx23]

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.

[@vadimyemets5910]

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

[@gmoniava]

undefined behavior is a bad feature of the language

[@karlsassie8403]

Everybody in the comment gushing about rusts safety; Guy guy have you seen C++23

[@Spartan322]

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.

[@atijohn8135]

it's the other way around: the first occurence (on page 3) _does_ include rust, the second one (on page 5) doesn't. either way, makes you wonder _why_ did he chose the list without Rust in it, as opposed to the one that had it.

[@StanleyPinchak]

​@@atijohn8135cry about it. Oh wait...

[@tcioaca]

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.

[@ignrey]

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

[@igo9481]

Rust Simps all over the comments 😂

[@svenkratz7552]

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

[@rad3km]

Unfortunately many Rust libraries use unsafe stuff where undefined behavior can be accidentally introduced (IMO rules for aliasing reference types are easier to violate in unsafe Rust than in C++).

[@thodono7466]

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

[@IsmeGenius]

As with all things C++ you have to learn not to do it or to rely on your static analysis tools (good luck with both of these).

[@jhk578]

accessing a moved object is a unspecified behavior. you don't wanna touch the object after you moved. afaik.

[@theKStocky]

std::move doesn't do anything to an object. It just performs a cast. Your constructor which takes an r-value reference, is perfectly valid if it does nothing to the object. e.g. try moving a struct which just has some floats and ints. Nothing will happen to it.

[@bart9522]

This is a prime example of something that static analysis can catch.

[@khatdubell]

The entire point of move is to mark to the compiler that you're finished with an object. Its a promise that you won't touch it again. if you touch it again, you lied and the compiler can do whatever it wants. You're lucky its throwing an error.

[@dera_ng]

Can't wait for Carbon Lang enough 😓😪 (Rust is pretty fabulous).... I do understand all arguments and the perceived dip in care/quality of code from newer generation programmers however I guess C++ will continue to remain like this for reasons best known to the maintainers. C++ will have its use cases. New projects should simply use Rust and stop fighting C++.

[@noobyfromhell]

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

[@zhaoli2984]

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.

[@rutabega306]

Naw backward compatibility is the most important part of c++. Don't want to support older versions? Make a new language!

[@andrewzmorris]

If you're breaking backwards compatibility, why not just use Rust?

[@wewlad5643]

Changing 1% of your code with a grace period and a warning flag instead of a complete rewrite from 0?

[@valmirius]

The cruft mountain will be even worse in the decades to come if they don't do it. In reality, they need a way to allow incremental changes across the codebase with newer versions. Circle is the only compiler that seems to have figured this concept out

[@bhz8947]

He certainly addressed *why* (in his opinion) that’s not the right route-repeatedly and in numerous ways-and you didn’t address any of his reasons in your comment. All you did is make an assertion without argument as if your reputation preceded you.

[@discoverii7142]

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

[@moonquake1881]

“Being careful does not scale”. Later “we must eliminate dangling pointers”, how ? “Be careful who’s the owner, be careful not to let the pointer slip past the intended scope”. Sorry, I love C++, but it’s broken beyond repair exactly because of that. Fixing this would mean implementing rust-style scope enforcement, which cannot simply built using some new crazy templates. Oh how much I hate C++…

[@KX36]

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

[@binary132]

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.