Is it not possible to use a linter with C++ that can tell you when you have done X or Y incorrectly?

surely, there is tooling that can help right?

It is possible to use C++ with a linter to help detect errors, but linters do not catch all errors nor do linters always understand what you are trying to.

Most approaches to using C or C++ safely involve throwing out large portions of the language and disallowing features that are easy to misuse or problematic to analyze for safety.

Not all of the issues you can create in C++ are visible at compile time. That’s kind of the point.

A lot of the time you’re going to need to lean on Valgrind. And that’s AFTER you shipped a fatal crash and you’re parsing a tombstone.

Often no, for multiple reasons.

Separate compilation means that even if you write an interprocedural static analysis system (quite a bit more complex than what most people would call a linter), you still run into oodles of hard boundaries where you can't look into other functions. Fixing this requires explicit annotations all over the place to even have a chance.

C++ is also a remarkably complex language in terms of aliasing relationships. There are a bazillion ways you can make two names alias each other. This gives you a few options when writing an analysis. You can be sound and do weak updates everywhere, which means your alarms will basically never be confident. You can be unsound and assume no aliasing, which means that you've got a lot of false alarms. You also can't really make a rule "don't ever create aliasing relationships" because they are often idiomatic C++.

And finally, the key properties that people really deeply care about like heap lifetimes fundamentally involve complex reasoning about both temporal properties, dataflow, and heap shape. All of these are hairy static analysis problems. In combination, a nightmare.

Maybe. But my employer doesn't have those tools. Assuming we're a median team, then half of all c++ teams don't do any static analysis or even know how to use valgrind properly. (The only tools that looked useful to me were the ones that incurred a thousand x slowdown, and our code is too crappy to run correctly at different speeds)

Almost every feature is a good thing. But the total quantity can become a bad thing, because the interactions between the features become more and more complicated. It's almost like features have values proportional to the number of features, but they have costs proportional to the square of the number of features. You eventually reach the point where new features add more cost than they add value.

But it's not that simple, because each new feature adds value to a subset, but adds costs to everyone. If the subset is vocal, they often get what they want, even if it's a net loss for all users taken as a whole.

So the trick is, first, to stop adding features once the costs outweigh the benefits, and second, given that you have only a finite number of features that you can add before you reach that point, to add the total set of features that are going to make the most valuable language.

Yes but actually no. In rust the compiler handles interactions between features for you. C and c++ don't. Per my previous Lego analogy.

"Sure, returning a reference to a local variable is a warning, but it's not an error, right? Many less-healthy teams probably ignore those warnings."

Seriously?