Re: [boost] [containers review] A reminder that the containers review ends tomorrow
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).
Review of Boost.Contianer by Zoltán Tóth 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 a Standard requirement, not specific to VC. Stephan T. Lavavej Visual C++ Libraries Developer
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
participants (3)
-
Ion Gaztañaga -
John Maddock -
Stephan T. Lavavej