I think that argument had more merit back when C++ was a much simpler language.

I've been programming in C++ since 1991, and the language / standard library are now so complex that it's hard to be 100% confident that I understand the meaning of any non-trivial code.

I have to massively disagree here. I'm far more confident about code written in the modern style of C++ than I am in old school C++.

Modern C++ with RAII, smart pointers, constexpr, concepts, and heavy instrumentation is so much easier to reason about. It's actually close to Alexander Stepanov's idealised C++.

Maybe we're talking about different subsets of C++.

IIUC, you're referring to codebases which limit themselves to what's often called "modern C++".

I'm working with codebases that draw from a gnarly combination of older and newer parts of the current language spec.

So in my experience, very few C++ programmers are familiar with every part of the current language spec that has relevance to these codebases.

I.e., their code isn't obviously correct regarding many aspects of correctness, including memory safety.

I can only partially agree. The new stuff often breaks in much nastier ways when it does eventually break. The worst of that old school C with objects code (and the toolchains that built it) can be dissected using simple tools and a lot of single stepping. Even when things miscompiled, you had a reasonable shot of figuring out the boundary conditions so you could avoid it in the future.

A lot of the modern stuff isn't like that. There's a thousand different rules governing ten thousand different constructs that interact in fun and dangerous ways.

You must have had incredible luck to never have made a mistake, even ones you didn't realize you made.

Hate that all you want, but you know it's true if you've been in the industry for more than a couple of years.

It's a mistake to cater to the lowest common denominator. We'll all be coding in Scratch in a decade if we keep down this path.

> C++ is only "memory-unsafe" if you are hiring bottom of the barrel talent.

Stated differently-- a bad hiring process can never raise the risk of memory corruption when you use a memory-safe language.

Even if I took your word for it: are you surprised a government would hire as cheaply as possible?

Having worked in government: Well, yes. Defense contractors aren't cheap, and they could probably hire cheaper talent if they were motivated/willing to clear away some red tape. That said, not everyone at a defense contractor is exactly top talent.

Can we please be responsible professionals and move past this. This was settled many years ago.