On 02/23/2010 03:07 PM, Daniel James wrote:
On 23 February 2010 09:02, Andrey Semashev<andrey.semashev@gmail.com> 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.