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:
>> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk