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.
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.
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.