Re: [boost] [unordered] unordered_set::erase() complexity bug?

Subject: Re: [boost] [unordered] unordered_set::erase() complexity bug?
From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2010-03-15 16:44:36

On Mar 15, 2010, at 4:33 PM, Daniel James wrote:

> On 15 March 2010 20:11, Howard Hinnant <howard.hinnant_at_[hidden]> wrote:
>> 
>> I'm reviving an old thread with new information:
> 
> Thank you, that's very useful. I think I'll add quick_erase in this
> release and deprecate the function I added in the last release (sigh).

Ok, note that the committee didn't decide on quick_erase.  The issue is still open.

> 
>> where node_ptr is a nested typedef in the container to unique_ptr<__node, __node_deleter<__node_allocator>>.  With this tool one can remove a node from a container, change its value, and insert it back into the container (or another which has an equal allocator).  E.g.:
> 
> You probably know better than me, but I don't think you can use
> unique_ptr like that with the new allocator requirements.

Just for clarity's sake, the unique_ptr should hold a reference to the container's deleter, not a copy.  So users of the node_ptr would need to watch out for lifetime issues (the node_ptr should not outlive the container which produced it).  I consider that a small price to pay for the functionality/performance gained.  But it /is/ inventive.

-Howard