C++ creator rebuts White House warning
infoworld.com
infoworld.com
No, Bjarne needs to realize that RAII and smart pointers are an old concept now, and they have shown to be insufficient, for decades now.
The bar for safety has been raised, and the Modern C++ is so behind, they don't even understand the issue, and still talk like it's about the C sins, or programmers not using it properly, or "but what about other bugs?".
The contemporary C++ is still a safety-third design where safety always loses to performance and backwards compatibility. The std::span has been standardized without .at(), and they're just getting around to adding it. Bounds checking by default on `operator[]` is one thing where C++ could be on par with Rust right now, but that is going to be relegated to an optional profile.
it is wrong to force safety onto the programmer especially if there is a cost to be paid to obtain it
and writing software in c++ does not imply the software is unsafe
That being said, I've fallen in love with Rust and have no intention of ever going back to C or C++.
The gripe is that after using them for a while, anything else like java, python, c++ or C is underwhelming, boring and tedious, an exercise in how long you can uphold standards until you fall back to language defaults.
We had languages that were a pleasure to use for high level programming abstractions, while at the same time, provided the necessary features to go all the way down, even inline Assembly if it must be.
Without the culture that tooling much be hard, rather developers are users as well.
Thankfully a new generation of developers is bringing this culture back.
I don't follow this. Could you elaborate?
I think the current culture is that tooling must be smart, accessible, and very well written, e.g rust (cargo, rustc, clippy, rust-analyzer), go coming with everything, same for gleam. Even zig is a better build system for C programs than most buildsystems for C.
Think TP, Delphi, VB, .NET, Smalltalk, Common Lisp, Clipper, Eiffel, MacOS AppToolbox, Java,...
Same applies to Herb Sutter's efforts, as of his recent blog post.
It doesn't matter how much tooling there has been available on the C and C++ ecosystem, a large majority will keep programming as they always did unless forced by external factors to change their ways.
Lint was created in 1979, and to this day many developers refuse to adopt static analysis on their C and C++ projects, let alone more modern tooling.
Technology cannot change community culture.
C++ barely made sense in 1995. It makes absolutely no sense today.
and i don’t want to learn another language and package management system
For me it was the only language I could see myself using after getting used to Object Pascal quality of life, in tooling, type safety, and language features.
C felt jurassic already in 1993, and there wasn't any other portable alternative I could reach for.
However that copy-paste compatibility with C is what definitly has made it unsuitable for writing safe code nowadays, specially with the C culture that is now left.
Those of us that like C++, but also are on the safety side, have already embraced other programming languages, relegating C++ for the absolute must use cases.
I wasn't really convinced and am more in agreement with this response to Stroustrup[2] from an embedded Linux developer. To quote from near the end of their response to Stroustrup:
> In the meantime, it is unfair for Dr. Stroustrup to call safe programming languages novelties or to pretend that C++ isn’t already far behind the times on this. This was already an important criticism of C++ decades ago, when Java first came out in the 90’s and was referred to as a “managed programming language.”
I'm not really buying that C++ is really all that commonly safe when we have stats like these[3]:
> A recent study found that 60-70% of vulnerabilities in iOS and macOS are memory safety vulnerabilities. Microsoft estimates that 70% of all vulnerabilities in their products over the last decade have been memory safety issues. Google estimated that 90% of Android vulnerabilities are memory safety issues. An analysis of 0-days that were discovered being exploited in the wild found that more than 80% of the exploited vulnerabilities were memory safety issues 1.
> The Slammer worm from 2003 was a buffer overflow (out-of-bounds write). So was WannaCry (out-of-bounds write). The Trident exploit against iPhones used three different memory safety vulnerabilities (two use-after-frees and an out-of-bounds read). HeartBleed was a memory safety problem (out-of-bounds read). Stagefright on Android too (out-of-bounds writes). The Ghost vulnerability in glibc? You betcha (out-of-bounds write).
[0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p27...
[1]: https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...
[2]: https://www.thecodedmessage.com/posts/stroustrup-response/
It's not. At this point, I cannot in good faith say that he is not lying, either to us or himself.
Although that's not much of a defense when he was the one who invented the wrong ways to use it.
https://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.pdf https://clang.llvm.org/docs/AddressSanitizer.html
In many cases we already have the tools. The problem is that people are not using them.
That said it is still in general a good thing to steer people away from C / C++ due to the languanges being very hard to use correctly.
Do you have a source for that claim?
The problem with these tools are that the instrumentation code inserted by the compiler comes with a 50-100% program-wide performance loss (*) and that's not acceptable to C++ developers. So in practice, you don't just add -fsanitize=address to your builds, you add it to test builds and fuzz them. But now you're not just trusting your compiler, you're trusting your tests and coverage.
The promise of Rust is that many of the memory safety bugs are forbidden at compile time in safe code, and the stuff that has to be checked at runtime (self referential data structures, out of bounds, etc) is able to be added more granularly with unsafe opt-outs where appropriate which means that you're not going to pay 50-100% in raw performance.
* take this like all perf numbers with a heap of salt, do your own benchmarks and come to your own conclusions.
I have always enabled bounds checking, and never ever, did it matter for the kind of projects I was involved with.
Not everyone is really writing a VR engine for a console rendering at 120 FPS, but just like everyone wants to be Google, so do much of those developers.
If you care about safety use gsl::span instead.
C++ does no good if you don't #pragma GCC poison all the C-isms.
AKA, we’ve created a messy monster that’s out of our control, please don’t blame us.
The same goes for cars. Thousands of people have died in car accidents yet nobody is proposing that we replace cars because if you use them correctly they really are quite useful.
The same goes for C++. I see a lot of C++-bashing on this thread (it seems very popular on HN?) but it is a useful language. I have worked with plenty of people who used it wrong but to throw the entire thing into the bin is blaming the wrong thing. People can be dangerous drivers even if the car is really good.
I have written professionally in C++ for 20 years now, and I would pick Rust for a _new_ project/fresh codebase in a heartbeat. tokio alone is so vastly superior to anything you can do in async C++ that it makes zero sense to select C++ for a _new_ project (obviously if you have an existing codebase the price of interop may not be worth it).
Bjarne is being deliberately obtuse here.
Wut, pretty sure the first aim was compatibility with C, the second aim was flexibility and overengineering, the third aim was performance. Safety was never on the list.
It's genuinely difficult to understand why Rust gets rammed down everyone's throats lately; do they really think developers coming out of universities today are too stupid to grasp memory management? If that's the case, why not have everyone code in Scratch?
That memo reads like "to avoid wet pants, everyone should now pee sitting down"; some of us can aim...
Or had a dangling reference in your program.
Yes. Experimentally, that is absolutely correct. New programmers are bad at memory management. So are old ones. So are experts, unless you seriously want to argue that the OpenBSD gang are a bunch of amateurs.
The best C/C++ programmers in the world still write code with memory flaws today. At some point you have to say, you know, maybe it's not the programmers that are the problem.
In the disciplines where real safety is required (like engineering, aviation, medicine), it's accepted that people will make mistakes. When a system can fail catastrophically due to a simple human error, it's the system that is broken, and needs to be made more robust.
I'm wondering if most folks throwing shade at C++ had used pre-C++11 toolsets and just have bad memories of the experience.
FWIW, I find modern C++ genuinely great to read / easy to parse by humans (same for similar languages like C#, Java, JavaScript/Typescript) whereas reading Rust (in particular function definitions) is painful.
Nobody promises that memory safety will fix all bugs, but it can prevent or significantly reduce a class of vulnerabilities, and reduce the total number of serious defects. And then time and effort saved on dealing with memory corruption bugs can be redirected towards dealing with all the other higher-level issues.
> Projects that use C the easy way have much better safety.
That's just another way of blaming programmers for not writing C without the bugs.
Every language can be perfectly safe if used correctly — even hand-written machine code. The problem is that it's easy to say "use C the easy way" (whatever that means), but actual real-world uses don't live up to such standard, and even the best programmers can make mistakes. Language safety is about making programs safer even when programmers write less-than-ideal code.
Rust is fairly explicit with what’s unsafe (ie unsafe) and safety is default. It’s also generally a simpler language overall with less accretion of backwards compatibility. There aren’t decades of bad habits still usable in rust. It’s got modern sugar, first class functional constructs, and it’s generally cooler in the way metal was cooler than big band was in 1988.
This argument reads like the old "Linux / macOS is safer than Windows, look at all the malware that targets Windows" while ignoring that at the time Windows had 95%+ market share for desktop.
Most software companies have a revolving door of developers and they need cookie cutter tools to limit the damage a "bad" developer can cause. In the 1990's Java OOP was hyped as the solution to procedural spaghetti code (because it is impossible to architect good software without objects), in the 2010's it was web frameworks (because it is impossible to build a web app without a framework), and in the 2020's it is Rust (because it is impossible to write C/C++/Assembly without memory bugs). The Rust hype cycle is yet another Big Corp push for more guardrails.