Delivering Safe C++ - Bjarne Stroustrup - CppCon 2023
Vložit
- čas přidán 23. 11. 2023
- cppcon.org/
CppCon 2023 Early Access: cppcon.org/early-access
Access All 2023 Session Videos Ahead of Their Official Release To CZcams. At least 30 days exclusive access through the Early Access system. Videos will be released to the CppCon channel on a schedule of one video per business day, with initial releases starting in November.
---
Delivering Safe C++ - Bjarne Stroustrup - CppCon 2023
github.com/CppCon/CppCon2023
Type safety was one of the key initial C++ design ideals. We have evolved C++ to the point where we can write C++ with no violations of the type system, no resource leaks, no memory corruption, no garbage collector, no limitation of expressiveness or performance degradation compared to well-written modern C++.
We face three major challenges: To define what “safe” means in the context of various C++ uses, to guarantee such safety where guarantees are needed, and to get developers to write such verified safe code.
I outline an approach based on safety profiles to address these challenges, describe an approach to eliminate dangling pointers, and suggest how to eliminate all dangling pointers and all range errors. My aim for key applications is verified type-and-resource-safe C++. An emphasis is on minimizing costly run-time checks through the use of abstractions. I see the current emphasis on safety as an opportunity to complete one aspect of C++’s fundamental aims in real-world code.
---
Bjarne Stroustrup
Bjarne Stroustrup is the designer and original implementer of C++ as well as the author of The C++ Programming Language (4th Edition) and A Tour of C++ (3rd edition), Programming: Principles and Practice using C++ (2nd Edition), and many popular and academic publications. He is a professor of Computer Science in Columbia University in New York City. Dr. Stroustrup is a member of the US National Academy of Engineering, and an IEEE, ACM, and CHM fellow. He received the 2018 Charles Stark Draper Prize, the IEEE Computer Society's 2018 Computer Pioneer Award, and the 2017 IET Faraday Medal. He did much of his most important work in Bell Labs. His research interests include distributed systems, design, programming techniques, software development tools, and programming languages. To make C++ a stable and up-to-date base for real-world software development, he has been a leading figure with the ISO C++ standards effort for more than 30 years. He holds a master’s in Mathematics from Aarhus University, where he is an honorary professor in the Computer Science Department, and a PhD in Computer Science from Cambridge University, where he is an honorary fellow of Churchill College. www.stroustrup.com
__
Videos Filmed & Edited by Bash Films: www.BashFilms.com
CZcams Channel Managed by Digital Medium Ltd events.digital-medium.co.uk
---
Registration for CppCon: cppcon.org/registration/
#cppcon #cppprogramming #cpp - Věda a technologie
Nice to see Bjarne looking so healthy. He appears to be younger than 10 years ago.
maybe he stopped programming
Agreed.
maybe he stopped programming in C++.
That certainly gives me white hair and a slight aneurysm @@BrainTrance
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.
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.
I would say that x[i] is mostly not needed. you can easily create sub spans now.
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)
It´d be a bit like Rust, right?
std::span `[]` is UB if you use index outside range. Correct example would be `std::map` where `[]` is safe.
Legend!
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.
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.
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.
I suggest looking up Circle first instead. That's a "CppFront" that's been around for what, 7-8 years at this point.
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.
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 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.
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?
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?
@@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.
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
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.
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.
Const correctness goes such a long way
Most awaited!! 😃
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).
"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
@@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
@@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.
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.
> 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.
Please, ABI break! We need it!!!!!!!!!🧡🦊
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.
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
such code would be very unpleasant to write and read
Oh man. I wish they had a language with affine types. That way you could have memory safety without a garbage collector.
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 :)
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.
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.
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++.
why are these videos not listed ?
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.
RUST
@@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.
@@boccobadzHave you ever written Rust?
@@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.
@@aarholodian Rust was encouraged by the U.S. government. That alone should make anyone hesitant to put anything with Rust code on their PC.
So wich is safest c++ compiler i can work??
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.
TIOBE is by no means an accurate measure of popularity.
thats what he said in the talk.
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.
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.
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
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.
@1:16:10 I'm confused. an immutable sting is just a const std::string, no? what's the deal?
when you have a reference to const std::string, some other code can have non-const references and can invalidate your iterators
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!
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.
Thanks a lot and respect, Bjarne! Simple rules to avoid safety issues, as earlier said Bjarne: use standard libraries and write good code!
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 think you might know already, but
LPCSTR: long pointer constant string.
which probably would be typedef'd to const char*
LPCSTR is just Microsoft's way of saying const char*
How about delive packet manager?
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.
Rust addresses the issue of backwards compatibility with the concept of Editions, which can indeed change most things and break backwards compatibility without affecting the rust ecosystem badly
Python and C++ - Winner Combination!
>>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 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 😉
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.
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).
@@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.
Because even mouthing the first letter of Rust makes the fanboys come out the woodwork
Rust wasn't listed in the cited NSA document. Nice try though 👍
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 ))
I always look forward to these keynotes. Thank you for sharing Bjarne, great material as always.
"If you're writing C-style code you should be horrified"
Better:
If you want to write C-style code, do it in C.
And be horrified.
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.
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...
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®."
on other news, a new salt mine have been discovered in the CppCon's basement
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.
@@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.
@@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.
@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.
Left Rust out of the list of memory safe languages.
C++ devs butthurt hearing about Rust
@@malborbossno it's just rusts terrible, toxic community
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!
500k/year to write 5 lines a day? It better be some insane code.
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.
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.
@@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
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.
@@Mobin92 jr commits: +200 -0
Mid commits: +500 -30
Senior commits: +100 -1000
It’s funny how he never mentions rust as an alternate language
funny way of spelling Typescript
"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.
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?
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.
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.
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.
@@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.
@@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..
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.
Skill issue
Overview video. No details here.
28:21 so this is how to open file
It's a shame to see that he uses const char* as a file path type.
@@petr_e haha 😂
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 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.
I'm going to design a language that I will call "Cex", just so that you can have "Safe Cex".
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.
I WTFd when he listed "security issues" almost completely unrelated to programming to dismiss memory safety
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.
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.
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.
I don't see any issue, could you please explain?
@@roh_son Same, what?
“use rust” - those are fighting words
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.
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.... 🙄
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'm curious about the guideline for safely using std::move. It makes the original object invalid and will cause run time error
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).
accessing a moved object is a unspecified behavior. you don't wanna touch the object after you moved. afaik.
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.
This is a prime example of something that static analysis can catch.
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.
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.
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.
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.
I dont think so, cause many programming language still dependent to C++
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.
C++ is never going anywhere
No one was laughing at his jokes, poor 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.
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 (czcams.com/video/qC5Po77bfKI/video.html)
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
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.
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."
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.
"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).
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.
C++ just need one things : an effective one element vector , not mor
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
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.
Ouch! That was a brutal takedown. Can you explain why? I'm genuinely curious.
Swift is my choice for new projects, and pure C for old projects!
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++.
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
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.
@@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)?
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).
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.
Naw backward compatibility is the most important part of c++. Don't want to support older versions? Make a new language!
If you're breaking backwards compatibility, why not just use Rust?
Changing 1% of your code with a grace period and a warning flag instead of a complete rewrite from 0?
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 😉
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++).
std::safe vs rust’s “unsafe”
let people opt-in, if it works - it will dominate
Isn't he the one who made "C++"
Hmm, you might be on to something. You should Google it.
Going from any language to another sounds like a biased decision without sufficient data.
Rust Simps all over the comments 😂
undefined behavior is a bad feature of the language
Just use rust lol
with the crap syntax arrows single quotes tons of ampersands and nonsensical things like that ? thank you ....
Step 1. Write Rust instead
i find it funny that he's just avoiding to say the word "rust" at all costs.
Step 2. Back to C++
Step 2. Get fired
You guys need to get another hobby
step 2 embed everything in unsafe { ... } when you want to do low level stuff
This lecture is a massive middle finger up to the NSA and the White House.
They could use more of those.
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
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 don't think you know what gas-lighting is.
Why do all Rust proponents seem like cultists?
We mustn't have watched the same talk then
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.
@@WilhelmDrake Because it's pretty much a cult.
I have to turn Bjarne down until I can barely hear him so I'm not deafened by his whistle.
ahahah
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.
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.
Oh please, go read a book if you want drama
@@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.
@@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®."
@@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.
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.
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.
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.
"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.
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.
@@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.
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++".
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.
why you don't want to use any of already existing languages without slow c++ standardization comittee and without backwards compatibility with c++?
Back compactibility is really important for code sustenance and development
@@SergePavlovskyConidering your aggresive replies here advise you to take a break.
Agree. He still dismisses breaking the backward compatibility. I am very disappointed. As long as they linkable, it is fine to me.
"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.
I hate smart pointer, thats it😢😢😢😢
“A lot of the so-called ‘safe’ languages outsource all the low-level stuff to C or C++,”
Shots fired.
...but they miss the target. It's far easier to get the implementation of these safe languages and/or system libraries correct, than teach each and every C++ programmer to only write safe programs.
Rust even has an "unsafe" keyword for that. It simply draws attention to the parts of the code that need extra, senior attention - and cost a lot more.
Slide 13: "This is not an excuse to ignore safety issues"
It’s also not true. You can write bare-metal code in rust, it’s very common in embedded dev.
Real low-level stuff is written in assembler.
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.
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.
@@atijohn8135cry about it. Oh wait...
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.
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.
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.
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.
Question, it's a c++ talk is it not?
2000 LOC per year is the point where Bjarne lost me. Why even deliver these talks if all you can muster is defensive BS?
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.
That train has already departed. There is a new king in town: R U S T