> It's very easy to beat up on vulnerable code and say it's "bad C++", but it's also irrelevant. Of course it was bad C++: it was vulnerable code. I'm not just

> It's very easy to beat up on vulnerable code and say it's "bad C++", but it's also irrelevant. Of course it was bad C++: it was vulnerable code. I'm not just beating it up as "bad C++" per se, I'm beating up the overall thoughtlessness of it all. Introducing a red-black tree, to plug a ownership flaw, is a sign things are dire. > Also, std::set is not memory safe. It is vulnerable to UAF due to iterator invalidation: iterate over a set and remove elements, for example. If you want to do that, then you shouldn't be using an ordered set. Doing so, for some arbitrary predicate, is O(n). Language is irrelevant. Why should the library make doing dumb things easy or safe? (Even though it did make a slight concession in C++11, at zero cost, by returning an iterator from std::set::erase). If someones first thought, when they find a library, which happens to not make something easy, is to shrug it off and write unsafe code, instead of spending 30 seconds re-evaluating their own decisions (whether wrt their own design, or using the library), then I'd say they're not a particularly good programmer. Now if you want to do something sane, like removing a range or an equal subset, then it's trivial of course: // remove 6 through 10, inclusive. s.remove(s.lower_bound(6), s.upper_bound(10)); // remove all the 42s s.erase(42);