------- Original message -------
From: Christian Schladetsch <christian.schladetsch@gmail.com> To: boost@lists.boost.org Sent: 23.6.'09, 17:23
On Wed, Jun 24, 2009 at 7:44 AM, Steven Watanabe <watanabesj@gmail.com>wrote:
AMDG
Christian Schladetsch wrote:
On Tue, Jun 23, 2009 at 12:29 PM, Felipe Magno de Almeida < felipe.m.almeida@gmail.com> wrote:
We should have interprocess STL implementation moved to a new namespace in boost.
What we really need is a STL implementation that allows for stateful allocators, as Stepanov first envisaged.
That's exactly what the containers in Boost.Interprocess do.
This would have been a useful piece of information to have when everyone was telling me that monotonic could not work because it had stateful allocators ;) I have redone a lot of this work in monotonic::container.
Now that I have made monotonic::allocator stateless and using regions and access types, it will be trivial to re-envision my original goal of true (and first-class re-entrant) local storage by using stateful allocators and boost::interprocess containers:
That´s good. The C++03 allocators requiring stateless allocators is just not enough. I think it is better to have a new set of allocators to be used with proper containers using a new allocator concept.
May I recommend that boost::interprocess::containers be moved to boost::containers?
I recommend it too.
The other thing I'd like is for map<> etc to ensure that new containers added to them use a rebound allocator. I do this for monotonic containers via a trait is_monotonic<Container>;
I don't think you should do that. It is unintuitive IMHO. Elements inside the map are different beasts. If the user wants to use the same allocator. Then he shouldn't use operator[]. Which default-constructs the object.
this relied on allocator::construct to always be called before a new object is accessed. However, some STL implementations use placement new after only calling allocator::allocate, which is terrible practice and should be fixed.
We must not require more than the C++0x requires I think. Though I´m not aware how the new allocators are. [snip]
Regards, Christian