C++ in Constrained Environments - Bjarne Stroustrup - CppCon 2022
ฝัง
- เผยแพร่เมื่อ 13 ต.ค. 2022
- cppcon.org/
---
C++ in Constrained Environments - Bjarne Stroustrup - CppCon 2022
github.com/CppCon/CppCon2022
C++ is widely used in constrained and/or critical applications and infrastructure components. How do we manage to use a large multi-purpose language in such environments? How can we better use facilities and techniques from modern C++ (C++11, C++14, C++17, C++20, and beyond)? The best answer is not “use only facilities available in C and C++ in 1985.”
This talk focuses on a top-down approach to achieve simplicity, maintainability, performance, and various forms of safety. It touches upon the C++ Core Guidelines, compile-time computation, type-and-resource safety, type deduction, the span and chrono standard libraries, and error handling.
---
Bjarne Stroustrup
Bjarne Stroustrup is the designer and original implementer of C++ as well as the author of The C++ Programming Language (4th Edition) and A Tour of C++ (2nd edition), Programming: Principles and Practice using C++ (2nd Edition), and many popular and academic publications. He is a professor of Computer Science in Columbia University in New York City. Dr. Stroustrup is a member of the US National Academy of Engineering, and an IEEE, ACM, and CHM fellow. He received the 2018 Charles Stark Draper Prize, the IEEE Computer Society's 2018 Computer Pioneer Award, and the 2017 IET Faraday Medal. He did much of his most important work in Bell Labs. His research interests include distributed systems, design, programming techniques, software development tools, and programming languages. To make C++ a stable and up-to-date base for real-world software development, he has been a leading figure with the ISO C++ standards effort for more than 30 years. He holds a master’s in Mathematics from Aarhus University, where he is an honorary professor in the Computer Science Department, and a PhD in Computer Science from Cambridge University, where he is an honorary fellow of Churchill College. www.stroustrup.com
---
Videos Filmed & Edited by Bash Films: www.BashFilms.com
TH-cam Channel Managed by Digital Medium Ltd events.digital-medium.co.uk
#cppcon #programming #coding - วิทยาศาสตร์และเทคโนโลยี
![[LIVE] : ONE ลุมพินี 72 วันนี้!! คู่เอก "ก้องศึก vs โจอาคิม"](http://i.ytimg.com/vi/hT1EOSsRPac/mqdefault.jpg)
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.
Always a pleasure to listen to Bjarne. One person I'd never watch at 1.5x speed
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!
Thank you Bjarne Stroustrup and cppcon for helping to educate the masses on programming with respect to the constraints/context of the situation given.
I love CppCon! Appreciate
Bjarne, your talks are always my favorite!
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.
"When you ask for something, and if you get it, you end up paying for it". Good stuff.
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.
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
Great overview of what C++ does in the wild and priorities for the C++ eco system.
"eco system" -)
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?
this is why we are love c++
Great Talk! Thanks!😀
awesome now if only people will listen and follow through
Verry impressive! simple and easy to understand. Also very helpful for experienced engineer.😁
Thank you so much for your comments which are much appreciated.
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.
slide 44, 47:47 (th-cam.com/video/2BuJjaGuInI/w-d-xo.html)
the check "if (s.size()
Good advice!
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?
Great Talk! Thank you! (=
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)
1:24:50 I really like Scala, because its compiling makes C++ looks faster
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.
Link for Slides, please.
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
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.
"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.
Better than rust?! I’m livid rn
Audio guys need to put some kind of de-esser
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.
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.
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.
1:23:20 :D
Slide 41: "auto px = unique_ptr(9)" .. this does not make sense. I think make_unique(9) was intended
Yes. Thanks!
I'm very interested in Bjarne Stroustrup can play chess or not? Please inform me. (I know people shouldn't have idols)
The only reason I use C++ is to be able to build desktop apps with Qt. If Rust, Nim, Zig, Odin were as well integrated I would switch immediately. C++ hast nothing to offer other than force of habit and spread.
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)
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.
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.
A talk about embedded.
volatile-deprecation.