Re: [boost] Proposal: Monotonic Containers - Comparison with boost::pool, boost::fast_pool and TBB

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:

> AMDG
>
> 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
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