Boost logo

Boost :

From: Samuel Debionne (debionne_at_[hidden])
Date: 2007-03-13 07:31:53

Dear all,
I'll try to give my point of view of Boost.Intrusive. I have been using
this library for a month (actually before the formal review begun) to
implement a triangulation data structure. I was interested in mainly three
features of these containers :

- the ability to get an iterator from an element in constant time
- a better memory management and cache friendly implementation
- the singly linked list which is not available in the STL

My first conclusion : Boost.Intrusive is an interesting library to me.
Let see more in details.

- What is your evaluation of the design?
The use of hooks is user-firendly and I appreciate to be able to choose
between member or base class hooks. Auto-unlink hooks are also intersting
but I did not have a try. The instantation of a container was not a
problem neither.
In the other hand, I didn't not inderstand why the containers implements
their own algorithm (reverse, remove_if, unique...) as member function.
Are there any reasons not to use their STL counterparts ?
Some of my comments overlay the documentation review, so see below.

- What is your evaluation of the implementation?
I didn't need to look at the inside of the library that much... which is a
good sign for a end-user review. Just one question : iterators couldn't be
implemented with iterator_facade ?

- What is your evaluation of the documentation?
The overall documentation is fine. It is written with QuickBook. About the
shape, I would put the usage before the concepts. And group "When to use"
together with the usages.
The text describing the concept is not what I expected and remains a bit
obscur. The concepts seems to be mixed with some implementation details.
In my opinion, this part should define first the different nodes concepts
(i.e. NodeSinglyLinked, NodeDoublyLinked...) that are the first template
argument of the containers.
The hooks are only helpers to make a class a model of these concepts.
Value traits is a also a helper, a "hook selector/adaptor", for classes
that model multiple nodes. They are not really concepts.
As far as I understand, node algorithms are also an implementation detail
that enable to share the basic mecanism of the container through several
instantion of the same container with different types (static function). I
would move this part to the design notes.
Did you consider using Boost.Concept to check the template parameter of
the containers ?
Finally, the different container and iterators concepts should be defined
(when they differ from STL, see bellow).
In other places in the doc, some requirement (i.e. smart pointer
requirement = TrivialIterator + get_pointer()) could be expressed as
concept or refinement of existing boost or slt concepts.

- What is your evaluation of the potential usefulness of the library?
I find it usefull and a good complement to their STL counterparts. As the
authors stated, I agree that this library is more a building block to
build other more powerful, encapsulated containers. To be used carefully.

- Did you try to use the library? With what compiler? Did you have any
Yes. I used the library with msvc8. No I didn't have any problems with the
library itself. But yes, I add some with its interaction with the STL.
Intrusive containers claim to offer an STL-like interface which is not
entirely correct.

For instance :

Mind the const. The Intrusive container member function push_back take its
argument by (not const) reference, since the node has to be modified to be

Here there are two options : either Intusive containers does not model the
BackInsertionSequence concept and that should be written in the doc or/and
some adapted insert iterator should be provided by the library.

- Do you think the library should be accepted as a Boost library?
Yes with minor corrections.

I would like to thank very much the authors for their great work.
Hoping that it will help,


HYDROWIDE Software Engineer

Boost list run by bdawes at, gregod at, cpdaniel at, john at