[boost] Re: Review Request: cyclic_buffer

From: Alisdair Meredith (alisdair.meredith_at_[hidden])
Date: 2003-06-09 11:53:30

Bo Persson wrote:

> Instead of dropping elements when the buffer is full, we might also
> consider waiting or throwing a failure.

"The one true circular buffer template" is a nigh impossible goal,
because it means so many things to different people.

A policy based approach would probably yield all the desirable
combinations of behaviour, but policy-based containers seem a hard sell
due to complexity of learning the interface.

The question of what to do when pushing new values into a full container
seems to be the key question though, and most likely to yield to the
policy approach.

One question that needs answering is what problem is the container
solving?

Last time I needed a circular buffer, I wanted fixed size (at compile
time) storing data samples (PODs or floats)  Using a fixed buffer solved
any memory fragmentation issues with extended running.  In my case I
simply wanted to overwrite the oldest data sample as new samples
arrived, as I was simply storing 4 minutes of data for viewing.  Values
wound never be popped, merely overwritten.

In this case, boost::array<N> would make a good base container.

Many other use-cases suggested over the evolution of this proposal have
made good cases for std::vector and std::deque.  Sometimes the buffer is
always full (eg my example above) in other cases comitted size varies as
items are push/popped.  Max size may be configured at compile-time, or
run-time.

I would certainly like the documentation to explain the tradeoffs made
in the implementation, and why this particular variation was chosen as
most appropriate for the general case.

-- 
AlisdairM