Re: [boost] [intrusive] Intrusive containers library strikes back

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2006-09-23 06:03:53

Hi Maxim,

----- Mensaje original -----
De: Maxim Yegorushkin <maxim.yegorushkin_at_[hidden]>
Fecha: Sábado, Septiembre 23, 2006 0:44 am
Asunto: Re: [boost] [intrusive] Intrusive containers library strikes 
back
Para: boost_at_[hidden]

> 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