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: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2009-06-23 17:04:06

------- Original message -------
> From: Christian Schladetsch <christian.schladetsch_at_[hidden]>
> To: boost_at_[hidden]
> Sent: 23.6.'09,  17:23
> 
> 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:

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