On Sat, 31 Dec 2005 18:01:00 -0200, Maxim Yegorushkin <maxim.yegorushkin@gmail.com> 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