I thought it was really profound when he said “once we’ve got vector and the equivalent, we don’t actually need arrays very much and we can do without new and delete in application code”. As someone who’s done a fair amount of rust, this resonated a lot as I realized that Rust and cpp are actually very similar. Rust has explicit language level unsafe while cpp has guidelines for abstracting safety. This foil is actually really interesting.
Much of this makes a lot of sense, but there are a couple of elephants in the room. 1) please pay much more attention to good naming if you want people to understand some of the essential ideas. For example, using scope based resource management is a great idea but calling it RAII is ridiculous. Ask anyone who has tried to teach C++ where the pain points are and you will quickly come across the silly names the C++ committee comes up with. SFINAE anyone? Or how about l-values and r-values? Kate Gregory is a good source on the value of good naming. 2) The committee takes pride in the long-term support of old code bases. This makes the language unnecessarily complex and less and less cost-effective each year. There's a reason why languages like Swift and Rust are increasingly popular. If we want to see C++ continue, (and I do), we need to acknowledge that ideas have matured over the decades and there's nothing to be afraid of in deprecating older ideas if you provide a migration path.
@@mikelopez9893 I think RAII is one of the better ideas though. Because it's not just scope based resource management. It's also the idea that if you're using constructors, you better have a very good reason to do so, i.e. some real resource acquisition. Moving data around is not constructing, there's a logic behind constructing objects. Compare this to other languages that made constructors basically a requirement for all of it's types. (Rust does not, they understood the _real_ idea behind RAII). Otherwise, yes, I agree some things are painful in that regard with C++. SFINAE, was an "accident" so it's not really that strange that it's named so horribly. Substitution failure is not an error - you can clearly tell it was discovered by accident, and it's also one of the core "ideas" (accident) behind template meta programming. But guess what, as C++ developers, only a microscopic minority ever does TMP. There are plenty of other things Rust also has a leg up on C++, I personally love both languages, particularly if we're speaking about modern C++.
@@mikelopez9893 I agree. Especially the second point :) The first point is also very important - So many fields (not only computer science, but all the other fields) use not very correct terminologies... But the problem is, they can't change the terms _because of the second point_ haha.
Thank you Bjarne Stroustrup and cppcon for helping to educate the masses on programming with respect to the constraints/context of the situation given.
B.Stroustrup: "A lot of people look for one solution to all of their problems: one facility, one tool, one language feature, one library...This is not my experience." Genius!
@D R Everything with c++ is too "manual", you have to learn cmake instead of just saying something like cmake init, cmake scan(to scan all folders and files) and everything is ready to work, conan can help with this but not easy to begin with too. And for a newbie everything is just so confusing, i know they don't want to make default stuff for c++ but IMO this mentality is outdated. Why not a default package manager with a default compiler. When you're learning to code and then you have to stop to learn how to pass flags in the compiler and what does these flags even do or how to use cmake to do make a library, it gets very annoying. I see some of these old people saying that the language needs to be simple for new people but what they think is a improvement is usually only a improvement for people who already knows the language.
One of the few talks I actually enjoyed listening from start to end in one sitting. Agree with all his points too. Nice comeback on compilation speed using Scala as a reference xD
Bjarne always has interesting large reaching talks at these conferences. Once you've heard a few of his, you've got the gist for most of them, but I enjoy them all none the less. It's general concepts to think about, regardless of the language or domain one works in, I believe. Not complex, not overly simple but clear and concise.
I have a C++ library that solves the bit manipulation problem you describe. By using strong typing, you can hide all the bit manipulation and make the code readable and very efficient. Not only that, it also hides hardware variations and allows for one templates function that works for very different hardware implementations. I.e an MCU with a 16 bit timer and 8 bit timer (like that found in an atmega 328pu). It's still a work in progress but it already works quite well.
I like the idea of this talk, bringing some common sense to C++ land which a lot of people feel is kind of bereft of it, but I don't like that it's apparently necessary. ALL platforms are constrained. Nobody has infinite RAM or CPU cycles, not even Google. If you're writing one-off scripts to automate bits of somebody's workflow, ok, maybe you're not likely to hit those constraints, but those of us writing consumer software will! How is it 2022 and we have an industry full of smart and hardworking people who need to be told this? "We must deal with real memory..." ALL MEMORY IS REAL MEMORY, BJARNE!
People need to be told. Look no further than Microsoft Teams, an Electron monstrosity that takes 700MB to start up and runs sluggish topend machines. Is Microsoft fixing this? Nope.
It must be strange being Bjarne, or really any core member of the C++ design team. You can look at almost everything you use on a daily basis and know that you had a big hand in making it possible, indirectly.
C++ doesn't have a design team. Design comes from proposals, and proposals can come from anyone. The committee only checks that the design is well defined, works with the rest of the language, and, now, that there's sufficient usage experience.
It's all about the difference between the flow of technical soap and the flow of thought of bio life. With the thought of bio, let's summarize the intelligent information activity of carbon life, we will use the word "bio". Bio thinks from one identification to another, while the flow of technical thought can and does operate in an endless and uninterrupted flow. And it is the speed, the very advantage of the flow of technical thought, that is based on the fact that it, the flow of technical thought, does not need to be identified, jump from point to point, it can flow without interruption. (Google translation interpretation)
Will the header files ever go away in C/C++ ? In other languages we don't have this concept. In java / go / javascript, we just import the packages we need and use them.
The man who created largest technical debt on the planet. Saved many machine cycles which otherwise would have been spent on type checking in interpreters.
Slide @ 6:50 is exactly why Rust can not replace C++...It not just the language... A large ecosystem of tools and infrastructure is involved in creating embedded products...
47:09, slide 43, I do NOT see why `f(a, 101)` would Ouch!! As long as `7 < n`, the function returns `p[7]`. Where is Ouch? Ouch will be when `a` declared to be size 7 or smaller, and the `n` is 8 or more!
When working on constrained systems, maybe every line does not need to be maximally optimised as you write it but not considering efficiency when writing every line on a constrained system is simply wrong. We all knew and had to deal with this when we had desktops with 32K of ram and MCUs with 4k.
I think the talk incidentally shows whats wrong with current c++. The assumption that the standard library can be used in the embedded environment, which in a lot of cases it can not. So in a lot of cases you are just stuck with union and don't even have the option to use variant. Basically a lot of improvements which would have been amazing for embedded developers went into the library instead of the core language....
@@bakedbeings many embedded developers (wrongly) think that including the STL library will increase the size of the firmware because they're stuck in the C++98 era and only see it as "C with bells and whistles", refraining from using anything more complex than pointers because of superstition. The truth is, the compiler doesn't make you pay for thing that you don't use, meaning that including a STL header won't include in the final binary the functions and the definitions that you didn't call.
Pattern matching: What is the rational of using yet more keywords for a slight variation of good old "switch-case"? Not only is it another new keyword, more new syntax, but sadly it also LACKS functionality of the switch-statement. Why not instead just make it a functional extension of the switch-statement? Why not have an attribute for non-fallthrough or fallthrough behaviour? It would even work if "switch" and "inspect" would work analogous to "struct" and "class" - same underlying principle but different default behaviour. *AND FOR THE LOVE OF GOD AND EVERYTHING*: Do NOT make single-character special identifiers that only have that meaning in one specific context. Yes - i am talking about the abomination that is '_' for what is a "default" in a switch-statement. That is just wrong.
Pattern matching is done very well in rust. It adds a lot of expressiveness, lacking in switches. I suggest taking a look at rusts version to see what they’re aiming towards
best answer: not use C++ at all. this language is preached to young nerds for 30 years by NGOs, commissions and consulting agencies indirectly funded by govts who extract money from taxpayers to fund this extremely unproductive method of developing applications. In the times of AI, quantum computing is ridiculous to agonize over tasks as simple as case insensitive compare of two strings or "rule of zero" when declaring a type and other such aberrations.
I did not remember how bad C++ is. I have not written C++ for a long time. I think I like Rust more. Sorry for that, once I really liked C++ verry much.
So, you say that something like this in Rust: Option state, accessed this way: state.as_ref().unwrap().member; would look moore clear that the C++ equivalent: std::optional state, accessed this way: state.value()->member For me the Rust syntax and standard function names is way more cryptic and inconsistent than the C++ one.
Rust will become complex and obscure the older it gets. C++ is actually BECOMING more usable and simpler over time, as it replaces old cumbersome features with newer, sleeker ones.
I heard this in 2004... Didn't happen then, won't happen now. First it was Java, then D, then C#, and now Rust that is supposed to change the world. Admittedly Rust looks like the first one that has a fighting chance in terms of the language, but "being the future" involves a lot more than just being a cool language.
Always a pleasure to listen to Bjarne. One person I'd never watch at 1.5x speed
I thought it was really profound when he said “once we’ve got vector and the equivalent, we don’t actually need arrays very much and we can do without new and delete in application code”.
As someone who’s done a fair amount of rust, this resonated a lot as I realized that Rust and cpp are actually very similar. Rust has explicit language level unsafe while cpp has guidelines for abstracting safety. This foil is actually really interesting.
Learning from the master. Such a clear minded man Bjarne is! Learning C++ from him is basically learning what a programming language is all about.
Much of this makes a lot of sense, but there are a couple of elephants in the room. 1) please pay much more attention to good naming if you want people to understand some of the essential ideas. For example, using scope based resource management is a great idea but calling it RAII is ridiculous. Ask anyone who has tried to teach C++ where the pain points are and you will quickly come across the silly names the C++ committee comes up with. SFINAE anyone? Or how about l-values and r-values? Kate Gregory is a good source on the value of good naming. 2) The committee takes pride in the long-term support of old code bases. This makes the language unnecessarily complex and less and less cost-effective each year. There's a reason why languages like Swift and Rust are increasingly popular. If we want to see C++ continue, (and I do), we need to acknowledge that ideas have matured over the decades and there's nothing to be afraid of in deprecating older ideas if you provide a migration path.
@@mikelopez9893 I think RAII is one of the better ideas though. Because it's not just scope based resource management. It's also the idea that if you're using constructors, you better have a very good reason to do so, i.e. some real resource acquisition. Moving data around is not constructing, there's a logic behind constructing objects. Compare this to other languages that made constructors basically a requirement for all of it's types. (Rust does not, they understood the _real_ idea behind RAII).
Otherwise, yes, I agree some things are painful in that regard with C++. SFINAE, was an "accident" so it's not really that strange that it's named so horribly. Substitution failure is not an error - you can clearly tell it was discovered by accident, and it's also one of the core "ideas" (accident) behind template meta programming. But guess what, as C++ developers, only a microscopic minority ever does TMP.
There are plenty of other things Rust also has a leg up on C++, I personally love both languages, particularly if we're speaking about modern C++.
@@mikelopez9893 I agree. Especially the second point :)
The first point is also very important - So many fields (not only computer science, but all the other fields) use not very correct terminologies...
But the problem is, they can't change the terms _because of the second point_ haha.
Thank you Bjarne Stroustrup and cppcon for helping to educate the masses on programming with respect to the constraints/context of the situation given.
B.Stroustrup: "A lot of people look for one solution to all of their problems: one facility, one tool, one language feature, one library...This is not my experience."
Genius!
Bjarne, your talks are always my favorite!
"When you ask for something, and if you get it, you end up paying for it". Good stuff.
Great overview of what C++ does in the wild and priorities for the C++ eco system.
"eco system" -)
Great talk, as always. I also dream of a future with a good package mechanism, especially newbie-friendly.
@D R Everything with c++ is too "manual", you have to learn cmake instead of just saying something like cmake init, cmake scan(to scan all folders and files) and everything is ready to work, conan can help with this but not easy to begin with too. And for a newbie everything is just so confusing, i know they don't want to make default stuff for c++ but IMO this mentality is outdated. Why not a default package manager with a default compiler. When you're learning to code and then you have to stop to learn how to pass flags in the compiler and what does these flags even do or how to use cmake to do make a library, it gets very annoying. I see some of these old people saying that the language needs to be simple for new people but what they think is a improvement is usually only a improvement for people who already knows the language.
Try conan. Its very simple. Basically a must
One of the few talks I actually enjoyed listening from start to end in one sitting. Agree with all his points too. Nice comeback on compilation speed using Scala as a reference xD
Bjarne always has interesting large reaching talks at these conferences. Once you've heard a few of his, you've got the gist for most of them, but I enjoy them all none the less. It's general concepts to think about, regardless of the language or domain one works in, I believe. Not complex, not overly simple but clear and concise.
I have a C++ library that solves the bit manipulation problem you describe. By using strong typing, you can hide all the bit manipulation and make the code readable and very efficient. Not only that, it also hides hardware variations and allows for one templates function that works for very different hardware implementations. I.e an MCU with a 16 bit timer and 8 bit timer (like that found in an atmega 328pu). It's still a work in progress but it already works quite well.
do you have a github link for your library?
I love CppCon! Appreciate
slide 44, 47:47 (th-cam.com/video/2BuJjaGuInI/w-d-xo.html)
the check "if (s.size()
I like the idea of this talk, bringing some common sense to C++ land which a lot of people feel is kind of bereft of it, but I don't like that it's apparently necessary. ALL platforms are constrained. Nobody has infinite RAM or CPU cycles, not even Google. If you're writing one-off scripts to automate bits of somebody's workflow, ok, maybe you're not likely to hit those constraints, but those of us writing consumer software will! How is it 2022 and we have an industry full of smart and hardworking people who need to be told this?
"We must deal with real memory..." ALL MEMORY IS REAL MEMORY, BJARNE!
People need to be told. Look no further than Microsoft Teams, an Electron monstrosity that takes 700MB to start up and runs sluggish topend machines. Is Microsoft fixing this? Nope.
Verry impressive! simple and easy to understand. Also very helpful for experienced engineer.😁
Thank you so much for your comments which are much appreciated.
awesome now if only people will listen and follow through
I don't know why it's called "C++ in Constrained Environments" instead of just "Good C++", but I enjoyed it anyways.
The compilation speedup with modules will be the number one reason why everyone will want to migrate to C++23 as soon as possible.
Modules are already in C++20.
@@kwanarchive Has GCC even finished their module support yet?
this is why we are love c++
It must be strange being Bjarne, or really any core member of the C++ design team. You can look at almost everything you use on a daily basis and know that you had a big hand in making it possible, indirectly.
C++ doesn't have a design team. Design comes from proposals, and proposals can come from anyone. The committee only checks that the design is well defined, works with the rest of the language, and, now, that there's sufficient usage experience.
It's all about the difference between the flow of technical soap and the flow of thought of bio life. With the thought of bio, let's summarize the intelligent information activity of carbon life, we will use the word "bio". Bio thinks from one identification to another, while the flow of technical thought can and does operate in an endless and uninterrupted flow. And it is the speed, the very advantage of the flow of technical thought, that is based on the fact that it, the flow of technical thought, does not need to be identified, jump from point to point, it can flow without interruption. (Google translation interpretation)
Great Talk! Thanks!😀
1:24:50 I really like Scala, because its compiling makes C++ looks faster
Good advice!
Will the header files ever go away in C/C++ ? In other languages we don't have this concept. In java / go / javascript, we just import the packages we need and use them.
They will never go away. But C++ has modules already. Use modules from now on, not header files.
Still waiting for the 2021 slides :D
Link for Slides, please.
"Battle not with error handling, lest ye become a error handler, and if you gaze into the C++, the C++ gazes also into you."
-- Bjarne, probably.
The man who created largest technical debt on the planet. Saved many machine cycles which otherwise would have been spent on type checking in interpreters.
Slide @ 6:50 is exactly why Rust can not replace C++...It not just the language... A large ecosystem of tools and infrastructure is involved in creating embedded products...
47:09, slide 43, I do NOT see why `f(a, 101)` would Ouch!! As long as `7 < n`, the function returns `p[7]`. Where is Ouch? Ouch will be when `a` declared to be size 7 or smaller, and the `n` is 8 or more!
It would be ouch because array a contains 100 elements. Pointing to a memory location outside the array is not good.
When working on constrained systems, maybe every line does not need to be maximally optimised as you write it but not considering efficiency when writing every line on a constrained system is simply wrong. We all knew and had to deal with this when we had desktops with 32K of ram and MCUs with 4k.
Great Talk! Thank you! (=
I think the talk incidentally shows whats wrong with current c++. The assumption that the standard library can be used in the embedded environment, which in a lot of cases it can not. So in a lot of cases you are just stuck with union and don't even have the option to use variant. Basically a lot of improvements which would have been amazing for embedded developers went into the library instead of the core language....
Why can't the standard library classes be used? Is that a limitation of the language or of the api/sdk provided by the device manufacturer?
Just asking, why the standard library can't be used in the embedded environment?
@@starriet e.g. AVR
@@bakedbeings many embedded developers (wrongly) think that including the STL library will increase the size of the firmware because they're stuck in the C++98 era and only see it as "C with bells and whistles", refraining from using anything more complex than pointers because of superstition.
The truth is, the compiler doesn't make you pay for thing that you don't use, meaning that including a STL header won't include in the final binary the functions and the definitions that you didn't call.
Pattern matching:
What is the rational of using yet more keywords for a slight variation of good old "switch-case"? Not only is it another new keyword, more new syntax, but sadly it also LACKS functionality of the switch-statement.
Why not instead just make it a functional extension of the switch-statement? Why not have an attribute for non-fallthrough or fallthrough behaviour? It would even work if "switch" and "inspect" would work analogous to "struct" and "class" - same underlying principle but different default behaviour.
*AND FOR THE LOVE OF GOD AND EVERYTHING*:
Do NOT make single-character special identifiers that only have that meaning in one specific context.
Yes - i am talking about the abomination that is '_' for what is a "default" in a switch-statement. That is just wrong.
Pattern matching is done very well in rust. It adds a lot of expressiveness, lacking in switches. I suggest taking a look at rusts version to see what they’re aiming towards
Rust.
Better than rust?! I’m livid rn
Audio guys need to put some kind of de-esser
28:35 Well, if C++ had true algebraic data types, a second test wouldn't be required.
The test would still be required. It just would be generated by the compiler, if it wasn't able to optimize it away due to compile-time knowledge.
I'm very interested in Bjarne Stroustrup can play chess or not? Please inform me. (I know people shouldn't have idols)
Slide 41: "auto px = unique_ptr(9)" .. this does not make sense. I think make_unique(9) was intended
Yes. Thanks!
1:23:20 :D
best answer: not use C++ at all. this language is preached to young nerds for 30 years by NGOs, commissions and consulting agencies indirectly funded by govts who extract money from taxpayers to fund this extremely unproductive method of developing applications. In the times of AI, quantum computing is ridiculous to agonize over tasks as simple as case insensitive compare of two strings or "rule of zero" when declaring a type and other such aberrations.
Who do you think writes the AI, and what language do you think makes AI actually fast enough to be usable?
@@kwanarchiveHaha, they think, because the high level api is python, it's not all c/c++ under the hood (or dialects like CUDA)
I did not remember how bad C++ is. I have not written C++ for a long time. I think I like Rust more.
Sorry for that, once I really liked C++ verry much.
Complexity and obscurity of CPP20/22 simply makes the language unusable. I think it will slowly go away into the past. Rust is the new future!
So, you say that something like this in Rust:
Option state, accessed this way:
state.as_ref().unwrap().member;
would look moore clear that the C++ equivalent:
std::optional state, accessed this way:
state.value()->member
For me the Rust syntax and standard function names is way more cryptic and inconsistent than the C++ one.
Rust will become complex and obscure the older it gets.
C++ is actually BECOMING more usable and simpler over time, as it replaces old cumbersome features with newer, sleeker ones.
I heard this in 2004... Didn't happen then, won't happen now. First it was Java, then D, then C#, and now Rust that is supposed to change the world. Admittedly Rust looks like the first one that has a fighting chance in terms of the language, but "being the future" involves a lot more than just being a cool language.
A talk about embedded.
volatile-deprecation.