On Wed, Feb 18, 2009 at 21:44, Robert Dailey wrote:

Wow, this is actually perfect. So before I do a rotate(), I need to do: schedule[0].clear() right? When I do future push_back operations on schedule[99], I want it to be adding to an empty vector and not adding to the old contents of it.

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

On Wed, Feb 18, 2009 at 21:58, Robert Dailey wrote:

On Wed, Feb 18, 2009 at 8:54 PM, Scott McMurray 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.