Olaf Krzikalla wrote:
the second version of intrusive containers is available.
Some thoughts based on a very quick look: I think you could allow ilist_node_d or ilist_node_m to be private, by using a mechanism along the lines of how boost::iterator_access is used with iterator facade and adaptor. I still feel a little uncomfortable with the: ilist<member<Vertex, &Vertex::prev, &Vertex::next> > form. Although allowing Vertex to be a POD is a very good reason for it. As before these members could be private. Also it would be nice to able to use a policy to define how the links are used - eg. if they're null when a node is not a member of a list, if the list is circular. I'm not sure how this could be used with a legacy structure otherwise (as it might make assumptions about its members). I don't believe an assertion that an inserted node isn't already in a list would cost much - it would be reduced to nothing in release mode. Alternatively, this is possibly another use for a policy, you could have no checks, or if it is in a list you could remove it, trigger an assertion, or throw an exception. Daniel