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:
>>> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk