Subject: Re: [boost] [Tokenmap] A (perfect) hash container library chcked-in to sandbox (RFC)
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-02-23 08:38:17
On 02/23/2010 03:07 PM, Daniel James wrote:
> On 23 February 2010 09:02, Andrey Semashev<andrey.semashev_at_[hidden]> wrote:
>>
>> In that case I would prefer the token generation mechanism to be separated
>> from the container structure. This would enable users to use tokens in
>> different containers, from STL to Boost.MultiIndex and Boost.Intrusive. The
>> proposed tokenmap would be equivalent to the standard unordered containers
>> with the tokened values then.
>
> I don't think you could do that without special support from the
> container.
Why?
> For MultiIndex you could implement a new index type. It
> could possibly reuse this implementation if it had some sort of
> ownership policy but MultiIndex normally implements that kind of thing
> itself.
>
> I can't see any benefit from Intrusive in this case. There are no
> collisions so there's no need to do anything like chaining the
> elements.
Session information in the suggested use case may not be suitable for
storing in a regular container (say, for the lack of copyability). Also,
I might want different access types to the collection of sessions,
token-based lookup being one of them. Boost.Intrusive is very efficient
in cases like these, and allowing to use tokens in intrusive hash
containers makes perfect sense to me.