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
One question that needs answering is what problem is the container
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
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.