|
|
|
|
|
|
by saghm
4 days ago
|
|
|
My point is that there are plenty of smart people touting various recipes for safe C++, but somehow vanishingly few instances of actually safe C++ codebases. It's hard not to feel like the claims that C++ can be made safe are mostly being made from an abstract theoretical viewpoint and not a pragmatic one, because even the companies with the most resources or the smartest people don't seem to be able to pull it off. |
|
|
Dennis Ritchie had this to say about C,
> Although the first edition of K&R described most of the rules that brought C's type structure to its present form, many programs written in the older, more relaxed style persisted, and so did compilers that tolerated it. To encourage people to pay more attention to the official language rules, to detect legal but suspicious constructions, and to help find interface mismatches undetectable with simple mechanisms for separate compilation, Steve Johnson adapted his pcc compiler to produce lint [Johnson 79b], which scanned a set of files and remarked on dubious constructions.
So lint aka static analysis, exists since 1979, and yet in 2026 one still has to advocate for stuff like clang tidy to be used.
Now you can argue that the right way would be to fix the language, not outsource to a linter, yes although the same could be told about clippy versus improving Rust.
Just like even though C++ frameworks always had the option to have bounds checking enabled, it took until C++26, under industry and government pressure, to make it officially part of the standard.
Community culture is a big deal, and hence why you don't see everyone using unsafe (or similar) all over the place in memory safe languages, and it is a big deal to even improve C and C++ safety by at least adopt the tooling that is already there.