1. One of the most important reason to replace the STL containers is the treatment of custom memory allocators. However the documentation tells only a single sentence about it: "Containers support stateful allocators and are compatible with Boost.Interprocess (they can be safely placed in shared memory). " 1. It does not specify how the containers are swapped: are the allocators swapped with the container?
If allocators don't compare equal, they're swapped. When Scoped Allocators are implemented according to the new standard allocators will be swapped when allocator_traits<allocator_type>::propagate_- on_container_swap::value is true. No problem to document this in more detail. In C++03 the implementor can suppose that two containers of the same type always compare equal, but this implementation pays attention on unequal allocator and swaps them in that case.
2. Most STL implementations have been supporting stateful allocators for years now. So it is not big news. However I am not satisfied with the way they might do it. For example Visual Studio's STL implementation require the allocator type to have a template copy constructor. Such allocator types are difficult to be implemented in efficient, threads-friendly way. (This is the reason I have implemented my own set implementation instead of STL::set) The documentation does not tell whether this library have a similar requirement. If no, that would be big news.
The library follows C++03 standard. I haven't seen any discussion about stateful allocators and thread-safety. If you have better ideas or extensions on this issue, I'm open to suggestions. Which problems do you see with the standard approach?
2. The documentation says: "All containers offered by Boost.Container can be used in recursive data structures, something that is not guaranteed by the standard". To understand the value of this feature better I as a user would like to know more about this topic. Please insert links or own text here that explain why does the standard not guarantee this. Is there any danger or difficulty in it? If yes: how does this library overcome them.
Well, recursive data structures are common data structures in computer science, but I'd try to add links and explanations. The standard does not guarantee this just because nobody has propose it. Several standard library containers are correctly instantiated with recursive data structures. You just need to keep some attention to avoid some early instantition: E.g. my Visual STL implementation compiles fine a recursive data structure with vector and list, but not with deque because it uses sizeof(T) too early in the deque implementation.
IMHO Boost.Containers should not (yet) be accepted (because of the lack of a detailed documentation).
Thanks for your time and your review. Best, Ion