[dataflow]

> If you don't do C++ on a daily basis, you will silently introduce problems

Even if you do, you still will. Just less often.

> I actually have no idea how big teams work on large C++ codebases... You can change one part of the code, and it will introduce bugs in the whole project because of how the memory is handled

Part of it is lots of tests, sanitizers, assertions, etc.

Part of it is keeping things modular and avoiding spooky action at a distance to the extent possible.

Part of it is unavoidable, and that's why people are moving to safer languages.

[unshavedyak]

Your post reminds me of the old runtime vs compile time language debates of old (for me). Some would argue duck typing is all that we need, and that lots of tests can cover the missing types/etc. Eventually i realized that i'm just manually implementing compile time typing by way of robust tests to cover interface requirements.

[sdeframond]

> Eventually i realized that i'm just manually implementing compile time typing by way of robust tests to cover interface requirements

This, so much this!

[dataflow]

Note that duck-typing can still be a compile-time thing: it's basically what you'd get in C++ if you use auto and templates for everything.

The trade-off between compile-time and run-time checking depends in large part on the time needed to address the issue. It's not really black and white. People just don't want to wait forever for static verification - I think that's kind of why clang-static-analyzer isn't used as much as clang-tidy.