Earlier quoted context omitted.
> C++ hasn't seemed to have changed that, either. C++ is not like C. Putting some C++ objects in a C codebase would, indeed, not change it much, but if you write in modern C++, some memory errors will literally disappear, and some become less likely. Caveat: This is based on language mechanics, standard library facilities and recommended idioms; of course people can write unsafe C++ if they want to.
And modern C++ features makes some memory errors more likely, e.g. dangling references from lambda captures and string_view/span. I'm not optimistic about the safety of modern C++. Most people who really care about safety long ago left the C++ building.
* Dangling references from lambda captures are no different than dangling references or pointers passed without lambdas, and not more likely to be used. * spans are no worse, and usually better, than using a raw pointer and a size; they don't make memory errors more likely. * string_view - indeed, it potentially introduces a dangling pointer. But - that only happens if you store it. Which is why I qualified my claim to "using recommended idioms". If you replace your `const char*` or `const std::string&` with `std::string_view` you have not introduced a potential memory error.
More generally - new language/library construct which do not manage their own memory can introduce memory errors. But, luckily, C++ now has a better "harness" of protecting you from many of these without costing you and performance nor introducing now memory issues.
So I stand by my claim. Having said that - C++ is not a safety-guaranteed language, and if that's what you need then it is indeed not the language to use.