More thoughts on invasive/intrusive containers and STL allocators

| 0 Comments

I'm still considering my options with regards to intrusive containers to replace the STL maps that I'm using in my timer queue implementation. I think I may be able to use the boost::intrusive sets in place of a true map in most of the situations that I need (I just have convince myself that a) it will work with all the compilers that I need to support, b) that adding a dependency to part of boost is a good idea for me and my clients and c) that even though my gut reaction on seeing the code is that it's pointlessly clever and bound to be a bitch to debug it's probably better than rolling my own).

I can't help but think that this whole issue would have never existed if the standard STL allocators had taken the value type as an argument to allocate(), this is likely not possible with things other than std::set and std::map BUT if these took the value type as a parameter then a custom allocator could simply locate the intrusive link structure in the value type and return that to the container. The same underlying map template could then work with either an allocator that allocates its node structure or an allocator that obtains the intrusive structure from the value type... Since it would have been this simple we'd have had the option of intrusive STL containers from day 0...

It's very tempting to hack this kind of change into a copy of the map/set/tree templates used in STLPort rather than writing my own...

Leave a comment