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?