&gt; It&#x27;s very easy to beat up on vulnerable code and say it&#x27;s &quot;bad C++&quot;, but it&#x27;s also irrelevant. Of course it was bad C++: it was vulnerable code.<p>I&#x27;m not just beating it up as &quot;bad C++&quot; per se, I&#x27;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.<p>&gt; 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.<p>If you want to do that, then you shouldn&#x27;t be using an ordered set. Doing so, for some arbitrary predicate, is O(n). Language is irrelevant.<p>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&#x27;d say they&#x27;re not a particularly good programmer.<p>Now if you want to do something sane, like removing a range or an equal subset, then it&#x27;s trivial of course:<p><pre><code>    &#x2F;&#x2F; remove 6 through 10, inclusive.
    s.remove(s.lower_bound(6), s.upper_bound(10));
    
    &#x2F;&#x2F; remove all the 42s
    s.erase(42);</code></pre>