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

From: Maxim Yegorushkin (maxim.yegorushkin_at_[hidden])
Date: 2006-09-22 18:43:47

Joaquín Mª López Muñoz wrote:
> Ion Gaztañaga ha escrito:
> 
>> Kevin Sopp wrote:
>>
>>> Hi,
>>> I'm working on an intrusive dynamic multi-index container.
>>> I've got some code working which allows me to add sequential views
>>> at runtime. I wondered as well if it was possible to share code for common
>>> operations in these containers. AFAIK pointer containers are just adaptors
>>> over standard containers.
>> Sharing core operations is definitely a good idea. But that will also
>> set dependencies that you might want to avoid. For example one could
>> imagine these dependencies(-> means depends on):
>>
>> multi_index -> intrusive_multi_index -> intrusive
>>                                           ^
>>                                           |
>>              interprocess_containers  ----
>>
>> I don't know if Joaquín would want to add more dependencies to
>> multi_index. Maybe this also limits the Joaquin's development rate.
> 
> 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

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?