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: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2011-08-14 17:38:38

> 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