Hello Ion, This is not a review. I took 3 hours to read the docs, checks some tests, try to check some sources, but I am still not used to read so few comments in the code. I played a little with the library then, tried to encapsulate some std::auto_ptr<X> in the new containers and things like that. Based on that very little experience, I would like to share some thoughts and ask a few questions on the proposed boost.containers library. 1/ I would really appreciate that the docs were more complete, at least for the technical part. => ex : "flat_map : more memory friendly and with faster searches" => In what way? is the algorithm complexity lesser than previous systems? or do you mean that contiguous memory is more cache-friendly? => do you provide different kernel implementations? => is there a paper on the subject? => Is there an evaluated algorithm complexity for the stable_vector? => is memory contiguous like a std::vector? can I use memcpy on several elements? These are just examples of questions that I expect to be answered by the docs. EDIT : I read proposition to embed elements of Joaquin M Lopez Munoz's blog. This is exactly that kind of informations I am looking for. => For the tree class, I can't remember any tree interface in the std. Could you point me to some informations ? Sorry If I miss something obvious. 2/ I was surprised (in a good way) to see some Andrei Alexandrescu's code in the library. Will the Loki licence be shipped now with boost? (This is not a problem for me). 3/ A few tests might be added. ex: Test the fact the vector usually are contiguous in memory. I can write this one if you are interested. 4/ The 'move aware' containers are nice to use but as a drawback We are forced to use macro to define the types using the 'move' semantics. What other container libraries can this work be related to? There are some examples of containers requiring the value_type to support only the "defaut constructor + a swap() function". This is a concept I would really appreciate to see in boost.containers. In that case, I would very happily use this library. Otherwise I think I will stick with other containers classes. 5/ "The aim of the library is to offers advanced features" Is the proposed Boost.containers also an effort towards development of new features for containers? If that is the case, then what are the plans for the future ? Is there a roadmap? To sum up : I am surprised that such a container library was not already integrated in boost. This should be a nice addition. But at the moment I don't think I would use it: my main interest would be for the value_type supporting "defaut constructor + a swap() function" to be added to the library. I also would like more detais in the documentation. In my humble opinion, it would also be easier for exterior people to learn from and to contribute to your library if there were more comments in the code. I congratulate you and the other authors for your work and efforts, and wish you the best for the review. Best regards, Pierre Morcello -- View this message in context: http://boost.2283326.n4.nabble.com/boost-containers-remarks-and-questions-tp... Sent from the Boost - Dev mailing list archive at Nabble.com.