Type-and-resource Safety in Modern C++ - Bjarne Stroustrup - CppCon 2021
Vložit
- čas přidán 9. 06. 2024
- cppcon.org/
github.com/CppCon/CppCon2021
---
Complete type-and-resource safety have been an ideal (aim) of C++ from very early on (1979) and is achievable though a judicious programming technique enforced by language rules and static analysis. The basic model for achieving that was documented in 2014 and does not imply limitations of what can be expressed or run-time overheads compared to traditional C and C++ programming techniques.
Experience shows that this cannot be achieved without static analysis and minimal run-time support. For fundamental reasons this cannot be done even with such support if arbitrary legal language constructs are accepted while conventional good performance must be maintained.
The way out of this dilemma is a carefully crafted set of programming rules supported by library facilities and enforced by static analysis.
This presentation is based on the C++ Core Guidelines and their enforcement rules (e.g., as implemented by the Core Guidelines checker distributed with Microsoft Visual Studio). That is, the points made here are backed up by specific rules and supported by existing software.
---
Bjarne Stroustrup
Bjarne Stroustrup is the designer and original implementer of C++ as well as the author of The C++ Programming Language (Fourth Edition), A Tour of C++ (Second edition), Programming: Principles and Practice using C++ (Second Edition), and many popular and academic publications. Dr. Stroustrup is a Technical Fellow and a Managing Director in the technology division of Morgan Stanley in New York City as well as a visiting professor at Columbia University. He 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. His research interests include distributed systems, design, programming techniques, software development tools, and programming languages. He is actively involved in the ISO standardization of C++. He holds a masters in Mathematics from Aarhus University, where he is an honorary professor, and a PhD in Computer Science from Cambridge University, where he is an honorary fellow of Churchill College. Personal website: www.Stroustrup.com.
---
Videos Filmed & Edited by Bash Films: www.BashFilms.com
CZcams Channel Managed by Digital Medium Ltd events.digital-medium.co.uk
Register Now For CppCon 2022: cppcon.org/registration/ - Věda a technologie
I really like the direction C++ is going the `owner` keyword and static analysis. Every reasonable programmer has keep a track of what part of the program owns a pointer so its nice to see it formalized. Amused how Bjarne closed down the covariant return question at the end.
I love RAII !
It's good, but as this talk brings home, it's far too easy to violate ownership rules with aliasing.
Ok, so let's follow C++ Core Guidelines (backed up by appropriate static analyzer for enforcement) and we are type-and-resource safe!
Great talk :)
Got to learn a lot
thanks Bjarne, I hope you come back to visit us in Madrid :-)
yes Bjarne I have similar anxieties as a newly minted C++ programmer! Where are the static analyzers and useful abstractions like dyn_array?
I love this guy.
Hi,
I think there is a typo on slide 37…
if (p == v.end()) *p = 9;
should be:
if (p != v.end()) *p = 9;
yeah, what's that struck me as well
I think it means when we write
if (p == v.end()) *p = 9;
the compiler will pass and won't give any error message though we know it is wrong
Great talk :-)
16:00, a *default: return nullptr;* would be nice in this example.
You mention that static analysis can be expensive. But since it is local the results can be cached so that during developement only changes need to be analysed. This could be done on a function by function or even scope level and not just for each translation unit
Talking about software that should be trusted I wonder why nobody considers numeric overflows. Since introduction of C in the famous 1979 I believe all processors at that time delivered dedicated mechanism to support detection of it, probably mostly with some flags register. C decided to ignore it, which I believe through all those years led to countless errors. Why nobody considers option of performing calculation in secure way so you won't get 4G for unsigned if you cross 0 or you won't enter negative world if you increment short over 32k. This can be done easily and efficient, as there is dedicated hardware for it in every processor, that is stubbornly being ignored for over 40 years now. The current alternative now is manual check and not done with those flags, but by checking the values received after the calculation is done. Is it optimal? Even C# has it now.
The ARM cpus can be configured to trap on overflow. This is done by the ALU without additional opcodes so no extra cost unless it happens. I recently heard that Android uses this but can't confirm.
CPUs don't offer possibility to track all possible kinds of overflows. For example `uint8_t x = 0xEF; x
I agree with your points on pretty much every account, but I feel like I need to point out, that every point that was made so far (~35:00) was basically a reimplementation of a Rust feature.
Enforce initialization of objects? Enforced by Rust.
Variant instead of unions? It's a Rust enum.
These rules for pointer lifetime? That's the Rust borrow-checker.
That [[trusted]] annotation? That's the unsafe keyword.
All methods should be const if not required otherwise? That's the default for Rust.
The list goes on. Your outgoing words, why these are not enforced by default are not wrong. But at the same time the fact that they are not makes it much harder for newcomers to profit from these tools. And that kind of secure code in C++ is VERY verbose, much cleaner in Rust. I just felt that this needed to be pointed out, and that perhaps this could be more openly acknowledged, and perhaps there could be an effort to try and not make up new terms for known concepts (eg [[trusted]] vs unsafe).
You have a MUCH harder job than the Rust maintainers, and what you're doing there is a very good effort. Many of the concepts you talk about, that are enforced in Rust, were inspired by or pretty much already done at a smaller scale by C++. But it doesn't help anyone if the facts are not acknowledged, and it's a fact that Rust is way ahead of C++ in these regards, and that now C++ could learn from Rust, and perhaps should try and openly adopt its concepts without unnecessary changes, where it's possible.
Rust learned so much from C++ mistakes, now C++ is heading toward Rust's way. Interesting time ahead.
tl;dr "I'm a rust fanboy, look at me"
@@flisboac Says the C++ fanboy. He raises valid points that you have no answer to.
Well, these so called rust enums are usually called sum-types, tagged union or variant. So why did rust call them enum in the first place? I guess they took it from swift? :D
34:11
you can't get there, Bjarne. you'd need an affine type system and move semantics to be able to do typestates. which you can't have.
[[trusted]] is a horrible idea because it does not invalidate on change. Every time the code changes the trust should have to be given explicity again and again. This could be achieved using { code; } [[trusted ]] where checksum is a digest of the trusted source block.
*[[messy]]