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.