@@khatharrmalkavian3306, so do I. _Inclined_ to do that isn't something they are, I'd say. Yet I have seen them in the C++ Communities commenting and posting their stuff, and even redirecting C++ Links to their stuff. So, what do we know, right?!!
@@khatharrmalkavian3306 I listen to him, but hate C++. Before 20 years, after using C++ 20 years, I quited my relationship with this language. I acknowledge Bjarne's efford. But he could design a new language to replace C++ learning from the past. He didn't and now other clever people that hate C++ gave us the Rust.
Probably they use the word "hate" wrong as a non-native english speaker, as I did before I realized that is the wrong word. Native language matters, as C++ matters for Bjarne. 😄(I used C++ for 20 years, if it matters...)
@@khatharrmalkavian3306I know, but I think that "hate" you say comes from JavaScript engineers working one React app with Gajjillion Bytes of memory along with TailwindCSS.... Don't really see a difference between Heap allocated data and Array... No stack no heap... Just soy goodness... And when they encounter C++, since their CS fundamentals are too weak to withstand it... They "hate" it
55:40 Even without RAII you'd still have the same problem. A function wants to return but it can't free the resource. What do you do? Loop until it can be freed? Don't free it? Add to a list? The same applies to doing so in a destructor. Or maybe the abstraction is flawed if you can't free it on demand.
I've been spending some time learning F* (F star) and Lean4 lately, and I think there's a lot of ideas that could be taken from such languages to make it easier to write safe/correct C++ w.r.t. a given specification. It's important that programmers and engineers can write specifications within the same language, and the compiler help prove that some code meets those specifications. I think, C++ needs things like refinement types, proof types, etc, that can be used as to verify code, all within C++. Otherwise, what will inevitably happen, is these higher level languages with powerful proof checkers will consume C++ "legacy code" and convert it into the higher level language where these sorts of things can be done, and then it will be recompiled down to C or C++, or maybe even directly to binary via something like LLVM, and the new rule Sean Parent will be espousing is "Thou shalt not write raw C++".
Yeah it blows my mind that no mainstream language have embraced dependent types yet. Why not? Why not focus on getting the compiler to find as many bugs as possible at compile time. I have looked at Idris and these other languages but for me as a Haskell guy even that becomes a little bit too heavy. It is not for the faint of heart and there is a serious lack of learning material. The best language I have ever used is F#. It combines the ease of use of imperative languages with the safety and expressiveness of the FP world and the tooling is excellent. It seems that we are on the same page here with regards to compile-time checking.
@@torarinvik4920 right on. Templates are basically dependent types, but you,d have to gnarly tmp to get say some sort of types indexed on predicates or refinement types and there would be no help from the language like there is in F*, the smt aided solver helps a lot. I think its possible in a lang like c++ but youd have to squint and cock your head sideways for it to make sense. Afaik atm, a path might be encoding a sort of denotational symantics for c++ >> a DTT kernel w/ a rich effect system like F*, essentially a monad where you preserve the original program structure/meaning from the category of C++ to the category of the dtt kernel where you can do type level program verification using the same algos in well known proof assistants. At least thats were my heads at atm, the meanderings of my mind.
C++ is in desperate need of an edition system to permit the "Cpp2" concept Herb Stutter has been championing for years now. Bjarne is completely correct, C++ has the tools to write safe and performant code right now, and has doen for years. The problem is it has taken until recently to hone in on what the correct way to solve these problems in C++ is. Guidelines aren't good enough. People forget or ignore guidelines, if they're even aware they exist. Adding a C++ 2026 syntax would allow for new projects to be upfront about adherence to C++ guidelines, whilst still allowing full backwards compatibility and interop with existing code. That is what Rust got right. Having editions allows breaking changes without breaking anything.
How can you consider Rust a memory safe language when Rust considers leaking memory "safe". Gee, if the C standard said that leaking was safe then none of the CVEs attributed to C would be valid, which is obviously not logical... Rust is safer, but to coin it self as completely safe they simply said in the standard that leaking is considered safe, which is basically sweeping the problem under the rug and acting like nothing happned lol. C++ doesnt get credit points for being slightly memory safer than C, either you are memory safe or you are not.
@@AlFredo-sx2yy You can not have memory leak in Rust. You can leak in other language, like C, and if you dare to integrate/link with it, yeah, you wrap it in unsafe. That does not mean the rust is unsafe, it quite opposite. Rust is not 'saf-er', it strictly safe. You can not possibly write unsafe code with pure Rust.
13:40 That's wild, C without function prototypes. Just call the function and hope the argument types are the same as what it expects. These early C++ developments (prototypes, mangled names for linker) are fairly simple changes but effective in preventing a lot of hard-to-detect bugs.
Hmm, the NSA's list of safe languages is this: Examples of memory safe language include C#, Go, Java®, Ruby™, Rust®, and Swift®, looks like Bjarne did some tampering with this list on his slides...
@@dynfoxx Still shame on Bjarne for not going with the list that includes Rust, since out of the listed Rust is the only language with guaranteed COMPILE-TIME memory safety. No other language has that.
"Memory safety" isn't all there is to "safety". There are many, probably infinite, logic errors that Rust, or any "Memory safe" language wont help you catch. Memory safety could be specified with the proper tools provided to the programmer, and those same tools can be used to specify higher level safety properties that no compiler or static analyzer could possibly foresee. They can also be used to specify linear logics for say GPU programming in accelerated linear algebra libraries. While a research language, ATS is trying to tackle this issue, F* is interesting as well, hopefully we'll get a "systems programming" language that provides those features to the programmer. @@cyrusol
Im glad Stroustrup speaks so clearly against changing C++ in ways that makes old code not compile any longer with the "it's safer that way" argument. This encourages me to write a defect report after I reently discovered the library working grouped decided to remove a function from C++20 - even without prior deprecation - which I used already in classic C++ (ie. even before C++98) in perfectly safe ways. Worse, they left no easy alternative, though that function is very probably still available "internally" for the library implementers. So, to use C++20, I now have to re-implement a function which is still available "under the hood" only because some other developers could have used that function in "unsafe" ways. By that line of argument one might even remove "reinterpret_cast" because it can be used in unsafe ways too (btw. even "static_cast" can be used in unsafe ways) and require developers to use #asm instead.
@@gblargga little bit simplified (hiding the real template definitions that parametrize the char-type and the char-traits) but enough to get the idea: std::operator>>(std::istream&, char*) has been replaced by a template std::operator>>(std::istream&, char(&)[N]) with the well-meant intent that the actual buffer size is extracted from the second reference argument - given this is actually an array. This is all fine and nice, but IMO it would have been sufficient to ADD the new function. Because eg. In the embedded world there are (proprietary) string classes with lower overhead than Standard String which may have a pointer `ptr` to `num` chars, typically encapsulated in a class, say `MyString` together with more convenience operations (like assignment and comparisons) in operator notation. This worked fine and nice since C++98 and up to C++17 and therefore the following was a perfectly safe way (ie. no risk of buffet overflow at all) to implement an input operator for `MyString`: std::istream& operator>>(std::istream& s, MyString& t) { return s >> std::setw(t.len) >> t.ptr; } With the omission of the pointer version for reading into a char array the above code doesn't compile any longer and a "clean" solution would mean you explicitly reimplement a functionality that's still there "under the hood" as since C++ 20 the replacement version will just delegate to it (as eg.in glibc++).
@@mittelwelle_531_khz That's surprising. I can see an issue with the original operator in that there's no compile-time checking that you remembered to set the length. I'd have expected at least a normal two-argument function to input n characters to a pointer. I've avoided iostreams from the beginning due to their high overhead and complexity for very simple things.
@@gblargg my point is that the overload resolution can differentiate between the two cases, especially if the new version should work as a "seamless drop-in replacement" out of the box". Of course it would not work as such if there are intermediate call levels where the original array decays into a pointer. What the "inexperienced" developer then might do is carrying the templated "reference to array" argument through all the intermediate functions causing a huge potential increase of code size, as many new template instantiations will typically be created with the sole purpose to communicate a compile time constant to an (internal helper) function which finally uses it as runtime argument anyways. Note that even the new version obeys std::setw and reads only that many characters even if the supplied array had more space. Btw. I typically use input streams in combination with std::getline into a std::string from the original stream source) which I then turn into std::stringstream from which I can parse several expected variants until one fits, exactly how it was/is also possible with sscanf in C. If you only deal with parsing simple, hunan readable text-based communication. protocols (or trivial command languages) it's usually much simpler than throwing the input against a regular expression (or even using boost::spirit::qi as replacement for good ol' lex-yacc 🙂).
as someone who has written some amount of rust and nearly no c++, it is super interesting to watch this because what Stroustrup is advocating for is basically how rust forces you to work. Not saying this to devalue this talk, but rather to mention how these ideas have actually made it into concrete results.
Eh i flinch when he says "I'm an engineer not a mathematician, having sometimes almost never happen is often good enough." In particular given the talk has no solution for iterator invalidation, though it does at least acknowledge it. The worst C++ codebase bugs that took the most effort to resolve in my career were all these. The problem with an invalidation bug, besides it occurring in code that generally seems compliant on code review, is that it is "almost never" apparent, that you need millions of iterations of the software for it to become obvious, as for a number of containers, only a small number of nominal invalidation events lead to true invalidation (i.e. vector gets resized) and even after deallocation, there is still usually a valid looking ghost data behind a dangling iterator, hiding the bug some more. And there's really no accepted or published modern-C++ way to guard it that i know of. When you have a software which has networked, and soft-realtime components, it tends to become impossible to automatically instrument the software to track down these issues precisely, you need a static compile time solution. You can't accidentally produce an iterator invalidation in Rust.
As a mostly C++ guy, who has yet to learn Rust, from what I hear, I agree that modern C++ code that follows best practices is very similar to Rust. I don't see why new projects would choose C++ over Rust, since they target the same niche, but Rust does it without 50 years (including C) of baggage.
The fact that Rust exists is evidence that C++ got complacent. It might have been better to deprecate some things and break older code. Tough call though.
13:00 having already programmed in C around the time Bjarne Stroustrup's article about C++ was published in the BSTJ (don't remember whether it was in the October issue of 1982 or 1984) IMO the statement that C didn't check argument types wasn't quite right. At least not at this time, the mid 1980s (before C adopted the C++ way of defining argument types in the ANSI/C89 == ISO/ C90) it could already do so with a slightly different syntax (repeating the argument type and name after the closing parentheses and before the opening curly brace or the semicolon in case of an exten declaration). Furtherrmore, also at that time, many developers didn't call the C compiler in the right way which was lint *.c && cc *.c but all too often used a plain cc *.c which was meant as shorthand after minor changes not requiring any extended (type) checking 😊😊.
What's really annoying about the captions is that they are saying "C" at several points instead of "C++" when a) the speaker is clearly saying C++, and b) the speaker made it clear early in the lecture that C++ is not C and vice versa.
"Just put 5 more pages into the core guidelines (which is a 1000+ page pdf by the way) that will surely make people write better c++". This dude's mental.
@@dariuszantoniukI imagine they're considering making the leap to node.js. Webapps are all the rage these days, and it's important for them to stay within fashion
I don't know why nobody ever mentions what languages those "memory safe languages" were written in: C/C++ If they were not written in C/C++, they depend at one point on C/C++. Even the "memory safe" language Rust uses LLVM to compile its code, which was written in… C++. How can anybody create a "memory safe" language depending on an "unsafe language" or on something that was created in an "unsafe language". That doesn't make any sense. It either means that everything is unsafe or that C/C++ are not as bad as (almost) everybody says.
Not difficult at all. For example, if the language being compiled has type safe arrays, it can compile with array checks. The language being compiled and the language of the compiler have very little to do with each other.
When 99.9% of my code doesn't use pointer arithmetics, why do I still need to pay (in terms of safety / verifiability) for it? How hard is it to add compiler switches that allow everyone to enable specific features / disable specific unsafe features of the language when they are not needed? I'm rather disappointed, both of this talk as well as of the development of C++ safety features. It's barely more than "follow these guideline", which is like "don't do bugs". It's laughable.
There is no organization that believes that "C/C++" is a programming language. The term is referring to both languages as a pair, since they have significant domain and design overlap. Bjarne knows this and is joking/complaining that people still refer to them together, since he's been trying to develop C++ as a superior alternative to C.
@@khatharrmalkavian3306 But that's exactly the problem here, pretending that C and C++ are the same. They're not. You can use C++ just like C, but you also have many facilities which allows you to write safer code. Going with the "C/C++" approach works against improving the existing C++ applications - and no, we cannot rewrite anything in (assuming that's even desirable). We need to collaborate on this, all the actors involved.
Overly simplistic blanket statements from bureaucrats are cheap and should generally be discarded unless you are in direct business with them. Especially those whos' organization is implicitly untrustworthy and deals heavilly in ulterior motives.
@@mytech6779 Tinfoil arguments don't change the fact, that C++ has serious issues, including safety ones that need to be addressed. Developers have experienced e.g. iterator/reference invalidation way before NSA safety recommendations were published. Even builtin language feature like range-based for loop was fundamentally broken for over 10 years (temporaries lifetime issues - P2012, P2644, should be fixed in C++23)
Motorcycles are dangerous. They are also the fastest way to commute to and from crowded cities, especially in southern Europe. Of course, if you give a 18 year-old recently-licensed youngster a Ducati V4, what do you think it will happen? Is it the fault of the motorcycle? Just avoid dangerous procedures, that's it. Safest way is to use C-style free functions, RAII, lambdas and templates. That's it. Just avoid street-smarts C++.
Regardless of the religious arguments (about language wars), I think it is pretty cool that the legend himself is still around and giving talks.
"- Doctor, doctor, it hurts when I hit myself in the head with the hammer!
- So don't do it!"
Thank you, Bjarne! :-))
26:40
@24:20
That's great and all. But neither clang-18 nor gcc-13.2 support modules.
Feel like I'll be well into my thirties by the time this sees the light of day, but I hope they deliver on it.
Love a good Bjarne talk
Cool
I'm very found of C and C++, it's always interesting see Bjarne Stroustrup tell the details.
Regards
Jean-François
I want to love C++
Start coding in it and you will fall in love with C++.
@@ludvikjerabek 🤡
_"The people that chose C++ today are not stupid"_ - that's one for the haters out there to let sink in👌🏽
I think that the "haters" would not be inclined to listen to the author of a language that they've rejected.
@@khatharrmalkavian3306, so do I. _Inclined_ to do that isn't something they are, I'd say.
Yet I have seen them in the C++ Communities commenting and posting their stuff, and even redirecting C++ Links to their stuff.
So, what do we know, right?!!
@@khatharrmalkavian3306 I listen to him, but hate C++. Before 20 years, after using C++ 20 years, I quited my relationship with this language. I acknowledge Bjarne's efford. But he could design a new language to replace C++ learning from the past. He didn't and now other clever people that hate C++ gave us the Rust.
Probably they use the word "hate" wrong as a non-native english speaker, as I did before I realized that is the wrong word. Native language matters, as C++ matters for Bjarne. 😄(I used C++ for 20 years, if it matters...)
@@khatharrmalkavian3306I know, but I think that "hate" you say comes from JavaScript engineers working one React app with Gajjillion Bytes of memory along with TailwindCSS.... Don't really see a difference between Heap allocated data and Array... No stack no heap... Just soy goodness...
And when they encounter C++, since their CS fundamentals are too weak to withstand it... They "hate" it
55:40 Even without RAII you'd still have the same problem. A function wants to return but it can't free the resource. What do you do? Loop until it can be freed? Don't free it? Add to a list? The same applies to doing so in a destructor. Or maybe the abstraction is flawed if you can't free it on demand.
I hope one day we’ll get a package manager for C++ or something similar that’s still backwards compatible.
I've been spending some time learning F* (F star) and Lean4 lately, and I think there's a lot of ideas that could be taken from such languages to make it easier to write safe/correct C++ w.r.t. a given specification. It's important that programmers and engineers can write specifications within the same language, and the compiler help prove that some code meets those specifications. I think, C++ needs things like refinement types, proof types, etc, that can be used as to verify code, all within C++. Otherwise, what will inevitably happen, is these higher level languages with powerful proof checkers will consume C++ "legacy code" and convert it into the higher level language where these sorts of things can be done, and then it will be recompiled down to C or C++, or maybe even directly to binary via something like LLVM, and the new rule Sean Parent will be espousing is "Thou shalt not write raw C++".
Yeah it blows my mind that no mainstream language have embraced dependent types yet. Why not? Why not focus on getting the compiler to find as many bugs as possible at compile time. I have looked at Idris and these other languages but for me as a Haskell guy even that becomes a little bit too heavy. It is not for the faint of heart and there is a serious lack of learning material. The best language I have ever used is F#. It combines the ease of use of imperative languages with the safety and expressiveness of the FP world and the tooling is excellent. It seems that we are on the same page here with regards to compile-time checking.
@@torarinvik4920 right on. Templates are basically dependent types, but you,d have to gnarly tmp to get say some sort of types indexed on predicates or refinement types and there would be no help from the language like there is in F*, the smt aided solver helps a lot. I think its possible in a lang like c++ but youd have to squint and cock your head sideways for it to make sense. Afaik atm, a path might be encoding a sort of denotational symantics for c++ >> a DTT kernel w/ a rich effect system like F*, essentially a monad where you preserve the original program structure/meaning from the category of C++ to the category of the dtt kernel where you can do type level program verification using the same algos in well known proof assistants. At least thats were my heads at atm, the meanderings of my mind.
I'm hopeful that Herb Sutter's cpp2/cppfront will do much of this eventually, but only time will tell.
@@torarinvik4920 sadly, most languages nowadays in the mainstream still embraces the billion dollar mistake.
C++ is in desperate need of an edition system to permit the "Cpp2" concept Herb Stutter has been championing for years now. Bjarne is completely correct, C++ has the tools to write safe and performant code right now, and has doen for years. The problem is it has taken until recently to hone in on what the correct way to solve these problems in C++ is. Guidelines aren't good enough. People forget or ignore guidelines, if they're even aware they exist.
Adding a C++ 2026 syntax would allow for new projects to be upfront about adherence to C++ guidelines, whilst still allowing full backwards compatibility and interop with existing code. That is what Rust got right. Having editions allows breaking changes without breaking anything.
I like the back-propagating speech recognition.
Did they intentionally deleted Rust from the NSAs safe language list?
Indeed they did lmao
How can you consider Rust a memory safe language when Rust considers leaking memory "safe". Gee, if the C standard said that leaking was safe then none of the CVEs attributed to C would be valid, which is obviously not logical... Rust is safer, but to coin it self as completely safe they simply said in the standard that leaking is considered safe, which is basically sweeping the problem under the rug and acting like nothing happned lol. C++ doesnt get credit points for being slightly memory safer than C, either you are memory safe or you are not.
@@AlFredo-sx2yy You can not have memory leak in Rust. You can leak in other language, like C, and if you dare to integrate/link with it, yeah, you wrap it in unsafe. That does not mean the rust is unsafe, it quite opposite. Rust is not 'saf-er', it strictly safe. You can not possibly write unsafe code with pure Rust.
Yeah, it is listed in the original report from NSA, but looks like it was removed in Bjarne's paper. Weird...
The quote he uses is directly from the NSA advisory. It's just the latter list where they don't mention Rust.
13:40 That's wild, C without function prototypes. Just call the function and hope the argument types are the same as what it expects. These early C++ developments (prototypes, mangled names for linker) are fairly simple changes but effective in preventing a lot of hard-to-detect bugs.
Hmm, the NSA's list of safe languages is this: Examples
of memory safe language include C#, Go, Java®, Ruby™, Rust®, and Swift®, looks like Bjarne did some tampering with this list on his slides...
The quote he uses is directly from the NSA advisory. It's just the latter list where they don't mention Rust.
@@dynfoxx
Still shame on Bjarne for not going with the list that includes Rust, since out of the listed Rust is the only language with guaranteed COMPILE-TIME memory safety. No other language has that.
@@cyrusolThe Language that shall not be named!
@@dynfoxx yea, he definitely made a choice which one to include from, though
"Memory safety" isn't all there is to "safety". There are many, probably infinite, logic errors that Rust, or any "Memory safe" language wont help you catch. Memory safety could be specified with the proper tools provided to the programmer, and those same tools can be used to specify higher level safety properties that no compiler or static analyzer could possibly foresee. They can also be used to specify linear logics for say GPU programming in accelerated linear algebra libraries.
While a research language, ATS is trying to tackle this issue, F* is interesting as well, hopefully we'll get a "systems programming" language that provides those features to the programmer.
@@cyrusol
really nice topic
C++ numbawan!
"I am going to talk about safety." He started that presentation with a joke. Great Speaker !!!
Im glad Stroustrup speaks so clearly against changing C++ in ways that makes old code not compile any longer with the "it's safer that way" argument.
This encourages me to write a defect report after I reently discovered the library working grouped decided to remove a function from C++20 - even without prior deprecation - which I used already in classic C++ (ie. even before C++98) in perfectly safe ways. Worse, they left no easy alternative, though that function is very probably still available "internally" for the library implementers.
So, to use C++20, I now have to re-implement a function which is still available "under the hood" only because some other developers could have used that function in "unsafe" ways.
By that line of argument one might even remove "reinterpret_cast" because it can be used in unsafe ways too (btw. even "static_cast" can be used in unsafe ways) and require developers to use #asm instead.
What function?
@@gblargga little bit simplified (hiding the real template definitions that parametrize the char-type and the char-traits) but enough to get the idea:
std::operator>>(std::istream&, char*) has been replaced by a
template std::operator>>(std::istream&, char(&)[N])
with the well-meant intent that the actual buffer size is extracted from the second reference argument - given this is actually an array.
This is all fine and nice, but IMO it would have been sufficient to ADD the new function. Because eg. In the embedded world there are (proprietary) string classes with lower overhead than Standard String which may have a pointer `ptr` to `num` chars, typically encapsulated in a class, say `MyString` together with more convenience operations (like assignment and comparisons) in operator notation.
This worked fine and nice since C++98 and up to C++17 and therefore the following was a perfectly safe way (ie. no risk of buffet overflow at all) to implement an input operator for `MyString`:
std::istream& operator>>(std::istream& s, MyString& t) {
return s >> std::setw(t.len) >> t.ptr;
}
With the omission of the pointer version for reading into a char array the above code doesn't compile any longer and a "clean" solution would mean you explicitly reimplement a functionality that's still there "under the hood" as since C++ 20 the replacement version will just delegate to it (as eg.in glibc++).
@@mittelwelle_531_khz That's surprising. I can see an issue with the original operator in that there's no compile-time checking that you remembered to set the length. I'd have expected at least a normal two-argument function to input n characters to a pointer. I've avoided iostreams from the beginning due to their high overhead and complexity for very simple things.
@@gblargg my point is that the overload resolution can differentiate between the two cases, especially if the new version should work as a "seamless drop-in replacement" out of the box".
Of course it would not work as such if there are intermediate call levels where the original array decays into a pointer. What the "inexperienced" developer then might do is carrying the templated "reference to array" argument through all the intermediate functions causing a huge potential increase of code size, as many new template instantiations will typically be created with the sole purpose to communicate a compile time constant to an (internal helper) function which finally uses it as runtime argument anyways.
Note that even the new version obeys std::setw and reads only that many characters even if the supplied array had more space.
Btw. I typically use input streams in combination with std::getline into a std::string from the original stream source) which I then turn into std::stringstream from which I can parse several expected variants until one fits, exactly how it was/is also possible with sscanf in C.
If you only deal with parsing simple, hunan readable text-based communication. protocols (or trivial command languages) it's usually much simpler than throwing the input against a regular expression (or even using boost::spirit::qi as replacement for good ol' lex-yacc 🙂).
as someone who has written some amount of rust and nearly no c++, it is super interesting to watch this because what Stroustrup is advocating for is basically how rust forces you to work. Not saying this to devalue this talk, but rather to mention how these ideas have actually made it into concrete results.
Eh i flinch when he says "I'm an engineer not a mathematician, having sometimes almost never happen is often good enough." In particular given the talk has no solution for iterator invalidation, though it does at least acknowledge it. The worst C++ codebase bugs that took the most effort to resolve in my career were all these. The problem with an invalidation bug, besides it occurring in code that generally seems compliant on code review, is that it is "almost never" apparent, that you need millions of iterations of the software for it to become obvious, as for a number of containers, only a small number of nominal invalidation events lead to true invalidation (i.e. vector gets resized) and even after deallocation, there is still usually a valid looking ghost data behind a dangling iterator, hiding the bug some more. And there's really no accepted or published modern-C++ way to guard it that i know of. When you have a software which has networked, and soft-realtime components, it tends to become impossible to automatically instrument the software to track down these issues precisely, you need a static compile time solution.
You can't accidentally produce an iterator invalidation in Rust.
As a mostly C++ guy, who has yet to learn Rust, from what I hear, I agree that modern C++ code that follows best practices is very similar to Rust. I don't see why new projects would choose C++ over Rust, since they target the same niche, but Rust does it without 50 years (including C) of baggage.
@@SianaGearz Good comment.
you should try c++, it won't force you to do anything and quite literally will liberate you
The fact that Rust exists is evidence that C++ got complacent. It might have been better to deprecate some things and break older code. Tough call though.
13:00 having already programmed in C around the time Bjarne Stroustrup's article about C++ was published in the BSTJ (don't remember whether it was in the October issue of 1982 or 1984) IMO the statement that C didn't check argument types wasn't quite right. At least not at this time, the mid 1980s (before C adopted the C++ way of defining argument types in the ANSI/C89 == ISO/ C90) it could already do so with a slightly different syntax (repeating the argument type and name after the closing parentheses and before the opening curly brace or the semicolon in case of an exten declaration).
Furtherrmore, also at that time, many developers didn't call the C compiler in the right way which was
lint *.c && cc *.c
but all too often used a plain
cc *.c
which was meant as shorthand after minor changes not requiring any extended (type) checking 😊😊.
Mm
Lil LL l pp l0.😊
The captions are really distracting..
Not for people who need it.
@@zizlog_sound YT has support for that..
What's really annoying about the captions is that they are saying "C" at several points instead of "C++" when a) the speaker is clearly saying C++, and b) the speaker made it clear early in the lecture that C++ is not C and vice versa.
@@TerminalJack505 I particularly liked the part where it wrote "the SEA Committee" lol
We still can call delete on a const pointer after all this talk about security.
"Just put 5 more pages into the core guidelines (which is a 1000+ page pdf by the way) that will surely make people write better c++". This dude's mental.
Core guidelines can be automatically enforced with static tools like clang-tidy that are already in use
You didn't understand the talk.
The legend it self!!
Very nice presentation. The only thing that gets in the way is the annoying real-time caption generation.
Oh, the captions weren’t too bad. And very helpful for people like me with mild hearing loss.
This guy gave me a career... C++ forever.
Does the NSA know how much stuff they use, that is written in C++?
I know at least one big tool they use, that definitely uses it.
They know, that's why they complain.
@@dariuszantoniukI imagine they're considering making the leap to node.js. Webapps are all the rage these days, and it's important for them to stay within fashion
it's good to see that concerns are being addressed
👍
Approaching asymptotically I would say...
I don't know why nobody ever mentions what languages those "memory safe languages" were written in: C/C++
If they were not written in C/C++, they depend at one point on C/C++. Even the "memory safe" language Rust uses LLVM to compile its code, which was written in… C++. How can anybody create a "memory safe" language depending on an "unsafe language" or on something that was created in an "unsafe language". That doesn't make any sense. It either means that everything is unsafe or that C/C++ are not as bad as (almost) everybody says.
Not difficult at all. For example, if the language being compiled has type safe arrays, it can compile with array checks. The language being compiled and the language of the compiler have very little to do with each other.
think: the first C compiler wasn't written in C
When 99.9% of my code doesn't use pointer arithmetics, why do I still need to pay (in terms of safety / verifiability) for it? How hard is it to add compiler switches that allow everyone to enable specific features / disable specific unsafe features of the language when they are not needed? I'm rather disappointed, both of this talk as well as of the development of C++ safety features. It's barely more than "follow these guideline", which is like "don't do bugs". It's laughable.
So basically professor's answer to C++ safety issues: you should write better code, C++ already has all tools for that. Nice.
He is saying be a chad programmer or STFU
I hope the kind of organization which believes "C/C++" is a programming language won't get to decide what we should or should not use.
There is no organization that believes that "C/C++" is a programming language. The term is referring to both languages as a pair, since they have significant domain and design overlap. Bjarne knows this and is joking/complaining that people still refer to them together, since he's been trying to develop C++ as a superior alternative to C.
@@khatharrmalkavian3306 But that's exactly the problem here, pretending that C and C++ are the same. They're not. You can use C++ just like C, but you also have many facilities which allows you to write safer code.
Going with the "C/C++" approach works against improving the existing C++ applications - and no, we cannot rewrite anything in (assuming that's even desirable). We need to collaborate on this, all the actors involved.
Overly simplistic blanket statements from bureaucrats are cheap and should generally be discarded unless you are in direct business with them. Especially those whos' organization is implicitly untrustworthy and deals heavilly in ulterior motives.
@@mytech6779 Tinfoil arguments don't change the fact, that C++ has serious issues, including safety ones that need to be addressed. Developers have experienced e.g. iterator/reference invalidation way before NSA safety recommendations were published.
Even builtin language feature like range-based for loop was fundamentally broken for over 10 years (temporaries lifetime issues - P2012, P2644, should be fixed in C++23)
just checked and my C++ compiler still compiles C code, I believe this is a choice made by the creator and later designers of C++
Motorcycles are dangerous. They are also the fastest way to commute to and from crowded cities, especially in southern Europe. Of course, if you give a 18 year-old recently-licensed youngster a Ducati V4, what do you think it will happen? Is it the fault of the motorcycle? Just avoid dangerous procedures, that's it. Safest way is to use C-style free functions, RAII, lambdas and templates. That's it. Just avoid street-smarts C++.
You wish c++ was as cool as a motorcycle, it's just an old combine harvester falling apart, being slowly turned into a redneck house attachment lol.
@@ThinkingNow Keep it simple. Fortran doesn't seem to have a lot of memory problems, for example.
@@ThinkingNow lmao
If you can't write a "good" program in c++, it's not because c++ is a bad language, it's because you're a bad programmer. 😆
Hard cope.
What have u achieved...nothing haha
I bet, at the end he will turn C++ to Rust.😆