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 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.
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
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.
[[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.
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.
Ok, so let's follow C++ Core Guidelines (backed up by appropriate static analyzer for enforcement) and we are type-and-resource safe!
I love RAII !
It's good, but as this talk brings home, it's far too easy to violate ownership rules with aliasing.
thanks Bjarne, I hope you come back to visit us in Madrid :-)
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
Great talk :)
Got to learn a lot
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
yes Bjarne I have similar anxieties as a newly minted C++ programmer! Where are the static analyzers and useful abstractions like dyn_array?
16:00, a *default: return nullptr;* would be nice in this example.
Great talk :-)
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
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]]