|
Boost : |
Subject: Re: [boost] [unordered] unordered_set::erase() complexity bug?
From: Daniel James (dnljms_at_[hidden])
Date: 2010-03-15 16:59:11
On 15 March 2010 20:44, Howard Hinnant <howard.hinnant_at_[hidden]> wrote:
> On Mar 15, 2010, at 4:33 PM, Daniel James wrote:
>>
>>> 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.
Sorry, I should have been clearer, I was worried about the node
pointer. I don't think you can use a '__node*' with the new allocator
requirements. You can obviously get a pointer by from a reference, but
there doesn't seem to be a way to get 'allocator_type::pointer' back
later, since there's no longer a requirement for 'allocator::address'.
Daniel
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk