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 :]