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

From: Maxim Yegorushkin (maxim.yegorushkin_at_[hidden])
Date: 2006-09-23 15:15:37

JOAQUIN LOPEZ MU?Z wrote:

>> 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

I probably misnamed the concepts in the scheme.

>> 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?

I agree that it was satisfactory, just trying to get rid of false-perfectionism 
habit ;) Anyway, it's nice to see that the new intrusive container initiative is 
gaining momentum.