Re: [boost] [Tokenmap] A (perfect) hash container library chcked-in to sandbox (RFC)

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.