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: using interprocess::containers; { monotonic::local_storage<10*1024> store; { map<int, int, std::less<int>, monotonic::allocator<int> > local_map(store); } } May I recommend that boost::interprocess::containers be moved to boost::containers? 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>; 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. Can boost::interprocess::containers please be moved to boost::containers? At the same time, they can use a super-set of the std::allocator model and ensure that allocator::construct is always called rather than sometimes using allocator::constuct and othertimes using placement new. Regards, Christian