Most of the OP's points are valid, no denying that. But, looking at the myriads of properly working, fast, not 'exploding in your face at runtime', often even beautiful code produced in C++ despite these shortcomings: doesn't really seem like a poblem if one knows how to deal with it.
And that is the downfall of all programming languages/paradigms!
Does remote code execution due to use after free fall in the category of "properly working" and "exploding in your face at runtime"? I would think it does, and C++ is vulnerable to that like few other languages are.
That was mostly put in there as a transition from C. Modern C++ users shouldn't be using new / free at all, since shared_ptr (and weak_ptr, its counterpart) and unique_ptr basically cover all the use cases.
std::vector<std::string> v;
v.push_back("Hello");
for (auto&& s: v) {
v.clear();
std::cout << s; // use after free in modern C++
}
In any case, a std::vector<shared_ptr<std::string> > would actually avoid the issue in this particular case.
Use after free... is more about use of raw pointers IMO. I wouldn't describe that code to be a "use after free" at all. In most languages, you are simply not allowed to change the container at all. Iterator invalidation is a hard issue in any language.
shared_ptr is also not memory safe when combined with references, which you need to use to call methods on the shared_ptr'd object or to pass those objects to most functions.
Foo f;
DoSomething(std::move(f));
// can still use f here.So again, unless Foo f was composed of "raw pointers", even that kind of code is safe from "use after free" vulnerabilities.
Not exactly. Use after free, while indeed problematic, is not what I would consider proper code, and I think you're well aware of that :]