Boost logo

Boost :

From: Bruno Martínez (br1_at_[hidden])
Date: 2006-01-18 17:21:16


On Sat, 31 Dec 2005 18:01:00 -0200, Maxim Yegorushkin
<maxim.yegorushkin_at_[hidden]> wrote:

> The most common use cases for intrusive containers are:
>
> * when one would like to store non-copyable elements in a container
> * when it's beneficial to avoid needless data copy in performance
> critical
> applications

For me, it's the ability to get an iterator from a pointer.

> An intrusive container is not a container in a stl sense, since it does
> not own
> its elements. The sole purpose of an intrusive container is to
> establish
> ordering between elements. It's a user responsibility to keep an
> intrusive
> container up-to-date by calling replace() to alter fields upon which
> an order
> is established as well as erase the nodes from the container prior to
> node's
> destruction. Aside from that the look and feel are similar to those
> of an
> non-intrusive container.

Frecuently, I have the need to manage elements of some collection that
know their place in the collection, and are able to remove themselves when
deleted. What does the library do when destroying a non empty collection?
An an element of a collection?

> struct record;
>
> typedef multi_index_container<intrusive<record> > container;
>
> struct record : container::node_type {};

I like this very much.

> Current implementation although efficient and mostly functional is a
> proof of concept only. Further design work is required which we rather
> unclear about and therefore would like to poll for interest and
> suggestions.

I'm interested.

> Known limitations:
> * partial template specialization support is required

I don't care.

> * dereferencing an intrusive container iterator yields a constant,
> should probably return non-constant

I don't know.

> * safe mode is not implemented for make_iterator() exposed api

OK. That would be good, but I never used safe mode with multi_index. At
least I didn't know I was using it.

Bruno


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk