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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost