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 problems? 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 : back_insert_iterator<BackInsertionSequence>::operator=(const BackInsertionSequence::value_type&) 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 inserted. 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, Samuel --- HYDROWIDE Software Engineer http://www.hydrowide.com