It is not unfortunately. That's why we see memory safety being responsible for 70% of severe vulns across many C and C++ projects.
Some of the reasons include: - C++ does little to prevent out-of-bounds vulns - Preventing use-after-free with smart pointers requires heavy use of shared pointers, which often incurs a performance cost that is unacceptable in the environment C++ is used.
I don't think that's really a rebuttal to what they're trying to say. If the vast majority of C++ devs don't follow those two rules, then that's not much evidence against those two rules providing memory safety.
For performance, you'll have to be more specific about your shared pointer claims. But I bet that it's a very small fraction of C++ functions that need the absolute best performance and can't avoid those performance problems while following the two rules.
Very bold claim, and as such, it needs substantial evidence, as there is practically no meaningful evidence to support this. There are some real world non-trivial c++ code that are known to have very few defects, but almost all of them required extremely significant effort to get there.
I think a lot of the arguments around C++ for example being 'memory unsafe' is a bit ridiculous because its trivial to write memory safe C++. Just run -Wall and enforce the use of smart pointers, there are nearly zero instances in the modern day where you should be dealing with raw pointers or performing offsets that lead to these bugs directly. The few exceptions are hopefully with devs that are intelligent enough to do so safely with modern language features. Unfortunately, this rarely gets focused on by security teams it seems since they are instead chasing the newest shiny language like you mention.