Comment by wffurr | Hacker News Reader

Comment by wffurr | Hacker News Reader

Modern C++ can be a joy to write, and is fine for a lot of tasks. It's hard to beat the combination of performance characteristics and higher-level constructs.

The issue with C++ is that it's unsafe by default. Foot-guns abound. The right way is to make everything safe by default and provide an escape hatch when needed, e.g. Rust's unsafe or C#'s unmanaged.

Unfortunately, there's no way to "fix" C++ to be safe-by-default. Too much legacy code out in the world and no appetite in the standards committee for backwards-incompatible changes in future versions of the standard.

It seems obvious to me that e.g. C++2X should entirely drop some older, broken, unsafe concepts, e.g. auto_ptr is the first thing that comes to mind, but there's all kinds of gnarly bits that need to go, and just allow older code to continue compiling under previous versions of the standard.

That does leave libraries in a tough place - if your project wants to move to the (never going to exist) backwards-incompatible C++2X, they would need to update or remove all libraries not compatible with the new version.

But this seems like a way to eventually move the entire ecosystem to a better place. Possibly the only way.

IMO fixing the unsafety is impossible, because doing so would mean re-evaluating the very core idea of C++ that C is a suitable substrate for building a safe, expressive language on. We know from years of experience that C has plenty of footguns of it's own, and fixing them is not possible without a fundamental redesign of the language. Therefore, the foundation of C++ is already rotten.

If that foundation were to be redesigned one'd have to get rid of the current near-100% compatibility with C, making the interop no longer an argument for using C++. Add the fact that most real-world C++ code will also be incompatible, and the strongest argument for using C++ is gone (namely, the impressive ecosystem size and maturity).

At that point there'd be no more justification for the existence of C++ over Rust (or another language that takes Rust's good ideas and supersedes it).

The raison d'être of a safer C++ would be to enable staged, tool-assisted migration for the many hundreds of millions (billions?) of lines of C++ code in the world.

I think that's plenty of reason all by itself.

I wonder would a compile time switch that enbales 'safe by default' be an option. At least then it means programs could transition to becoming fully able to compile in this safe mode and only let subsets (e.g. certain files in a project or old libraries) use the unsafe by default mode. It would be less of a sharp shock and could allow people time to transition, and know where to spend efforts to become safer.

One thing we do in the Firefox codebase is build using a clang plugin that we wrote to statically enforce additional rules.

It’s not a perfect solution , and obviously not built in, but it is a big help for avoiding footguns.

You can do a lot to make modern C++ programming safer with linters, clang-tidy, sanitizers, valgrind, etc. But it's a lot of work and a lot of compute to bolt that on top of a fundamentally unsafe language. It's out of reach for a lot of organizations and requires a substantial amount of organizational coding discipline.

It's like the old saw that gets trotted out about C and C++; you can write safe code in any language if you're disciplined about it. The point of safe languages is to make it easy and accessible to write safe code; to design into the language a "pit of success" rather than requiring a big slog to make a flawed language usable.

Reply on news.ycombinator.com