Subject: Re: [boost] [unordered] unordered_set::erase() complexity bug?
From: John Zwinck (jzwinck_at_[hidden])
Date: 2009-11-26 18:17:21
Jeffrey Bosboom wrote:
> Getting back to this specific case, I think the two versions of erase()
> are different enough in performance to warrant providing both.
> Unfortunately, I don't know of a good alternate name for whichever one
> isn't named erase().
A name which is simply synonymous with "erase" may leave people confused.
I do think that creating a new function name is what's needed here so
that we may move forward with an obviously-viable solution (as opposed
to ones which may raise substantive objections, such as lazy evaluation).
I suggest augmenting the existing name: something like "erase_fast"
or even "erase_void" would be fine (at least until someone else comes up
with something better, for which there will no doubt be plenty of time).
As for the production code which I mentioned in my previous message, we
decided to deploy a solution which erases by key. This solution is
almost tragic, for we have the iterator in hand when we decide to
erase() it, but at least the performance doesn't blow up now.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk