Subject: Re: [boost] Proposal: Monotonic Containers - Comparison with boost::pool, boost::fast_pool and TBB
From: Christian Schladetsch (christian.schladetsch_at_[hidden])
Date: 2009-06-23 16:23:59
On Wed, Jun 24, 2009 at 7:44 AM, Steven Watanabe <watanabesj_at_[hidden]>wrote:
> Christian Schladetsch wrote:
>> On Tue, Jun 23, 2009 at 12:29 PM, Felipe Magno de Almeida <
>> felipe.m.almeida_at_[hidden]> 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
map<int, int, std::less<int>, monotonic::allocator<int> >
May I recommend that boost::interprocess::containers be moved to
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk