Subject: Re: [boost] Proposal: Monotonic Containers - Comparison with boost::pool, boost::fast_pool and TBB
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2009-06-23 21:07:27
Christian Schladetsch wrote:
>> I'm not sure I follow you. Where are the lists being created? [...] All I
>> see is integers being inserted in the list and a sort operation.
> For instance, MSVC creates temporary lists in std::list::sort:
> const size_t _MAXBINS = 25;
> _Myt _Templist(this->_Alval), _Binlist[_MAXBINS + 1];
> Note that the first temporary is made by at least passing the allocator -
> but the other lists are made on the stack using default construction, so
> there is no way to pass a statefull allocator as a parameter.
This is only a problem because the implementation of sort calls
_Splice which copies the nodes if the allocators are unequal.
>> This sort operation should only swap integers. And even if it did allocate
>> something, it should do with my_custom_allocator.
> But it doesn't - that is my entire point.
sort should not allocate anything, so in theory it should
not need to propagate the allocator.
>> But I'm not sure construct should be always called, and even if it is
>> I'm pretty sure they shouldn't be used to pass automagically the allocator
>> down with other containers.
> That is a seperate issue. What I do in construct is my own business ;) I'm
> just saying that with the current state of affairs, even
> boost::interprocess::containers do not work with stateful allocators. For
> example, interprocess::list is implemented using intrusive::list, which does
> the following in its sort method:
> list_impl counter;
> This invalidates the use of stateful allocators, because it is making
> multiple temporary lists that do not use the allocator that the parent
> container was supplied with.
No it doesn't. Boost.Intrusive doesn't allocate anything.
All that sort does is to rearrange existing nodes, so the allocator
is not needed. Boost.Intrusive doesn't even know that
an allocator exists.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk