Re: [Boost-users] A need for a complex pool type container

Subject: Re: [Boost-users] A need for a complex pool type container
From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2009-02-19 00:22:47

On Wed, Feb 18, 2009 at 21:58, Robert Dailey <rcdailey_at_[hidden]> wrote:
> On Wed, Feb 18, 2009 at 8:54 PM, Scott McMurray <me22.ca+boost_at_[hidden]>
> wrote:
>>
>> Yes, you will.  (I had thought you were popping tasks off the vectors
>> to run them.)  And be sure to keep the capacity and size of the
>> circular_buffer the same, or else the rotate will start copying and
>> destructing vectors.
>
> Well after I construct my circular buffer, I immediately do:
> schedule.resize( 100 );
>
> This should give it a fixed size, right? And as long as I never call any of
> the pop or push functions to remove/add elements, nothing should be
> allocated or freed by the circular buffer, correct again?
>

Correct.

I was referring to the allocation performed by the vectors, since
rotate will copy-construct if the circular_buffer's size is less than
its capacity.

>>
>> Of course, even on other containers you always have the option of
>>
>>    c.push_back(vector<T>());
>>    swap(c.front(), c.back());
>>    c.pop_front();
>>
>> which should also avoid any allocing or freeing by the vectors.
>
> I'm assuming "c" here is the circular buffer previously named "schedule"?
>
> Won't doing a push_back() and pop_front() cause an allocation and
> deallocation, respectively? the rotate() looked good because it did not
> actually add or move anything from the circular buffer itself.
>

I was using it for an arbitrary container.  The point is that while
the container might do allocation, the swap there prevents the bucket
vectors from needing to allocate when you refill it later.  As you
mention, rotate avoids the issue (if size == capacity).

On a circular_buffer, push_back wouldn't actually need to allocate
(though it would need more capacity than the rotate version), though
list, deque or most others would.  With a pool allocator, though, you
could plausibly avoid that issue, if you needed a different container
of buckets for some reason.  Clearly, though, it's a theoretical
exercise as circular_buffer seems to provide exactly what you need.