Hi Maxim, ----- Mensaje original ----- De: Maxim Yegorushkin <maxim.yegorushkin@gmail.com> Fecha: Sábado, Septiembre 23, 2006 0:44 am Asunto: Re: [boost] [intrusive] Intrusive containers library strikes back Para: boost@lists.boost.org
Joaquín Mª López Muñoz wrote: [...]
Maxim Yegorushkin's proposal for an intrusive multi_index_container (see at http://tinyurl.com/e5uac ) does not induce a new dependency on regular multi_index; instead, it is more of a side-by-side add-on:
multi_index ------------| ---> B.MI core intrusive multi_index --|
Another surprising feature of Maxim's proposal is its very small size, he manages to inject intrusiveness into B.MI by merely changing a couple of files and adding a handful of new ones! My intention is to wait for Olafs's (or now Ion's) intrusive library to start being discussed and then perhaps convince Maxim to adopt analogous design decisions for his proposal. I hope an intrusive multi_index_container can eventually make it into B.MI some day.
Sorry for being a bit too late. Now, having had a little more practice with intrusive containers, the following design might me more appropriate:
intrusive -> multi_index -> B.MI core
Umm? From your comments below, I guess you mean multi_index -> intrusive -> B.MI core ?
It appears that for most if not all node-based containers the non- intrusive version can be built on top of the intrusive one. The non-intrusive version just takes care of node memory management, what users of the intrusive version prefer do themselves. insert() allocates the node and pass it down to intrusive::insert, erase() invokes intrusive::erase() then deallocates the erased nodes. Does it make sense?
IMHO it does. But the approach you took in your intrusive_multi_index sketch seems to me equally satisfactory. Basically, node creation and destroying is very localized within B.MI, and, more importantly, is completely dettached from the implementation of the indices themseleves, so it is easy to provide different implementations for his aspect resulting in traditional and intrusive versions of the container. Maybe you're seeing a defficiency in your later approach that I don't see? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo