In legacy codebases, this is common, and I agree this is very painful. But in modern C++, it's pretty easy to write code that doesn't leak or dangle references.

In legacy codebases, this is common, and I agree this is very painful. But in modern C++, it's pretty easy to write code that doesn't leak or dangle references. Don't use new, don't use delete; no memory leaks (barring cycles w/ shared_ptr). Avoid raw pointers in favor of references, and there are only a couple of rare cases where you can have something dangle. In addition, the new sanitizers (asan, msan), do what valgrind does, but are about 10 times faster, that is they only slow your code down 2-3x. So you should be running it on your unit tests on a nightly basis, further catching any bad memory issues. On a green field project, you can write code like this and have processes like this from day one, and memory safety is not going to be something you spend much time on. I've worked on C++ codebases where I just never spent any time on this stuff, at all.