A popular conference talk has been making the rounds, praising C++26’s new safety features — erroneous behavior, standard library hardening, contracts — as the answer to decades of memory safety criticism.
These are massive, legacy-heavy codebases where much of the code predates modern C++ practices. Code written with raw new/delete, C-style arrays, char* string manipulation, manual buffer management — the full catalogue of pre-C++11 antipatterns. And there’s a conflation problem: the studies report “C/C++” as a single category. The Windows kernel is largely C, not C++. Android’s HAL and native layer are heavily C. Modern C++ with RAII, smart pointers, and containers is a fundamentally different beast than malloc/free C code, but the statistic treats them as one.
And then after the paragraph you quote, the author just blasts along with the conclusion that code should be rewritten in memory safe languages like Rust, Kotlin and Java, without even touching on their own observation that modern C++ facilities do make a difference to prevalence of bugs.
What is the reduction in bug rate when rewriting legacy C++ with raw memory management vs. modern C++ with RAII and reference counted pointers? We don’t know and they don’t want to ask, because it would challenge their main thesis.
I don’t disagree that modern C++ safety still relies on the programmer making the right choices, whereas with a truly memory-safe language the compiler makes those decisions for you. But to sidestep the question completely is disingenuous and serves to make those of us who actually care about the specifics (C++ programmers, the people they’re trying to convince to retrain) to be incredibly suspicious of the whole argument.
modern C++ facilities do make a difference to prevalence of bugs.
This is true, but just saying “write modern C++!” doesn’t actually work in practice. First, there are a ton of footguns that even best-practice C++ doesn’t avoid. Using std::shared_ptr? Great, you’re probably going to avoid memory leaks. Null pointer dereference? Not so much. What’s the modern C++ way to avoid integer overflow?
Second, it’s pretty much impossible to completely avoid raw pointers etc. even if you’re trying, and good luck getting your colleagues to actually try. I can’t even get mine to write proper commit messages. You need a machine forcing them to do it properly. Something they can’t opt out of (or at least where opting out isn’t the easy lazy option).
So yeah it’s better to use modern C++ and it is an improvement, but not enough the change the conclusion that you should just use Rust instead.
The preceding paragraph is this:
And then after the paragraph you quote, the author just blasts along with the conclusion that code should be rewritten in memory safe languages like Rust, Kotlin and Java, without even touching on their own observation that modern C++ facilities do make a difference to prevalence of bugs.
What is the reduction in bug rate when rewriting legacy C++ with raw memory management vs. modern C++ with RAII and reference counted pointers? We don’t know and they don’t want to ask, because it would challenge their main thesis.
I don’t disagree that modern C++ safety still relies on the programmer making the right choices, whereas with a truly memory-safe language the compiler makes those decisions for you. But to sidestep the question completely is disingenuous and serves to make those of us who actually care about the specifics (C++ programmers, the people they’re trying to convince to retrain) to be incredibly suspicious of the whole argument.
This is true, but just saying “write modern C++!” doesn’t actually work in practice. First, there are a ton of footguns that even best-practice C++ doesn’t avoid. Using
std::shared_ptr? Great, you’re probably going to avoid memory leaks. Null pointer dereference? Not so much. What’s the modern C++ way to avoid integer overflow?Second, it’s pretty much impossible to completely avoid raw pointers etc. even if you’re trying, and good luck getting your colleagues to actually try. I can’t even get mine to write proper commit messages. You need a machine forcing them to do it properly. Something they can’t opt out of (or at least where opting out isn’t the easy lazy option).
So yeah it’s better to use modern C++ and it is an improvement, but not enough the change the conclusion that you should just use Rust instead.