Re: [boost] [containers review] A reminder that the containers review ends tomorrow

Subject: Re: [boost] [containers review] A reminder that the containers review ends tomorrow
From: John Maddock (boost.regex_at_[hidden])
Date: 2011-08-14 04:28:36

> Just a quick reminder that the containers lib review ends tomorrow - there 
> have been lots of good comments, but not so many reviews - so now's your 
> chance ;-)  If there are any reviews pending that are likely to be late 
> please let me know so we can extend the review period.

This review was sent to me privately, posted here for comment:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Review of Boost.Contianer by Zoltán Tóth

I am not an expert of C++ containers topic, but use them daily in my 
algorithm programming job.

C++ 1998 STL containers have serious deficiencies, I would say especially 
node-based STL containers are not usable at all for performance-critical 
algorithms due to their memory allocator treatment/requirements. I have 
written own implementations for STL vector, set, list, ., because I was not 
satisfied with STL containers.
Therefore a replacement of those in Boost could be a terribly useful 
library.

I did not try to use the library. I just quickly read the documentation, and 
found that it is very poor.

Here are the deficiencies I have found in the documentation:

   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?
         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.
   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.

IMHO Boost.Containers should not (yet) be accepted (because of the lack of a 
detailed documentation).