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

@BrainTrance

2 ай бұрын

maybe he stopped programming

@cafetechne

2 ай бұрын

Agreed.

@soederwargestern

2 ай бұрын

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

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.

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

7 ай бұрын

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

7 ай бұрын

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

@etherstrip

7 ай бұрын

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

5 ай бұрын

It´d be a bit like Rust, right?

@von_nobody

5 ай бұрын

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

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

2 ай бұрын

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

2 ай бұрын

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

2 ай бұрын

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?

@me___5796

24 күн бұрын

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

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.

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

5 ай бұрын

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

5 ай бұрын

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

3 ай бұрын

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

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

5 ай бұрын

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

4 ай бұрын

Const correctness goes such a long way

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

Legend!

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

2 ай бұрын

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

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

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

@keris3920

5 ай бұрын

"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

5 ай бұрын

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

24 күн бұрын

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

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

@SergePavlovsky

12 күн бұрын

such code would be very unpleasant to write and read

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

why are these videos not listed ?

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

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

@antagonista8122

4 ай бұрын

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

3 ай бұрын

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.

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.

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

@SergePavlovsky

12 күн бұрын

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

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

5 ай бұрын

RUST

@boccobadz

4 ай бұрын

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

4 ай бұрын

@@boccobadzHave you ever written Rust?

@aarholodian

4 ай бұрын

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

24 күн бұрын

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

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.

@julians.2597

Ай бұрын

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

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

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

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

2 ай бұрын

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.

How about delive packet manager?

TIOBE is by no means an accurate measure of popularity.

@ino1729

2 ай бұрын

thats what he said in the talk.

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

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

2 ай бұрын

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.

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.

Python and C++ - Winner Combination!

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

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

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

5 ай бұрын

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

@destiny_02

5 ай бұрын

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

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

6 ай бұрын

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

6 ай бұрын

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

6 ай бұрын

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

5 ай бұрын

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

@hpesoj00

5 ай бұрын

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

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

"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

5 ай бұрын

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?

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

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.

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

10 күн бұрын

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

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

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.

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

@soniablanche5672

3 ай бұрын

funny way of spelling Typescript

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.

@Mobin92

6 ай бұрын

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

6 ай бұрын

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

6 ай бұрын

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

5 ай бұрын

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

5 ай бұрын

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

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

@lesto12321

6 ай бұрын

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

@connemignonne

6 ай бұрын

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

6 ай бұрын

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

@andrekostur2683

5 ай бұрын

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

5 ай бұрын

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

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

5 ай бұрын

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

2 ай бұрын

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

@DmitryBaranovskiyMrBaranovskyi

Ай бұрын

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

28:21 so this is how to open file

@petr_e

5 ай бұрын

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

@robervaldo4633

10 күн бұрын

@@petr_e haha 😂

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

@IsmeGenius

7 ай бұрын

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

7 ай бұрын

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

@theKStocky

7 ай бұрын

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

6 ай бұрын

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

@khatdubell

5 ай бұрын

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.

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.

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

5 ай бұрын

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

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

5 ай бұрын

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

5 ай бұрын

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

@chewey

4 ай бұрын

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

4 ай бұрын

C++ is never going anywhere

Overview video. No details here.

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

5 ай бұрын

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

5 ай бұрын

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

@Spartan322

5 ай бұрын

@@roh_son Same, what?

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.

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

5 ай бұрын

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

10 күн бұрын

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

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 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 (kzread.info/dash/bejne/o3dpstFwZ8XMe6w.html)

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

“use rust” - those are fighting words

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

19 күн бұрын

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

@andrewzmorris

18 күн бұрын

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

@kalebbarrett8419

11 күн бұрын

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

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

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.

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

6 ай бұрын

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

6 ай бұрын

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

6 ай бұрын

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

@Placeholderhandle1

5 ай бұрын

Did any of you watch the talk?

@user-nw8pp1cy8q

5 ай бұрын

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

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

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

21 күн бұрын

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

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.

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

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

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

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

@criptych

2 ай бұрын

They could use more of those.

@Phantom-lr6cs

11 күн бұрын

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

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.

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

7 ай бұрын

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

7 ай бұрын

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

7 ай бұрын

"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

7 ай бұрын

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

7 ай бұрын

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

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

6 ай бұрын

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

5 ай бұрын

Oh please, go read a book if you want drama

@JohnDoe-vb3ks

5 ай бұрын

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

5 ай бұрын

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

5 ай бұрын

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

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

@igo9481

4 ай бұрын

Rust Simps all over the comments 😂

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

@rad3km

5 ай бұрын

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

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.

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

@Dannnneh

2 ай бұрын

Hmm, you might be on to something. You should Google it.

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

5 ай бұрын

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

@Voltra_

5 ай бұрын

We mustn't have watched the same talk then

@deathlife2414

5 ай бұрын

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

2 ай бұрын

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

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

6 ай бұрын

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

6 ай бұрын

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

5 ай бұрын

Back compactibility is really important for code sustenance and development

@ekremdincel1505

5 ай бұрын

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

@junningli6506

5 ай бұрын

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

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

5 ай бұрын

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

4 ай бұрын

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

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

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

@user-sl4th2pu1z

5 ай бұрын

ahahah

Step 1. Write Rust instead

@none_of_your_business

7 ай бұрын

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

@UnrealEngine_Master

7 ай бұрын

Step 2. Back to C++

@wangyanzhao8475

7 ай бұрын

Step 2. Get fired

@hannesw8436

7 ай бұрын

You guys need to get another hobby

@IamJatin

7 ай бұрын

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

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

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

@januszkszczotek8587

6 ай бұрын

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

@M69392

6 ай бұрын

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.

@M69392

6 ай бұрын

Slide 13: "This is not an excuse to ignore safety issues"

@kiranshila

6 ай бұрын

It’s also not true. You can write bare-metal code in rust, it’s very common in embedded dev.

@user-nw8pp1cy8q

5 ай бұрын

Real low-level stuff is written in assembler.

Just use rust lol

@Phantom-lr6cs

2 ай бұрын

with the crap syntax arrows single quotes tons of ampersands and nonsensical things like that ? thank you ....

undefined behavior is a bad feature of the language

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

6 ай бұрын

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

5 ай бұрын

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

I hate smart pointer, thats it😢😢😢😢

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.

I am interested in how fast the rest of the talks will be uploaded to youtube? 1 every 2 weeks? Every other day @CppCon

@etherstrip

7 ай бұрын

They mentioned one every day, starting around the end of the year.