Use boost::circular_buffer:

[nbougalis]

The existing code used std::deque along with a size check to constrain the size of a buffer and, effectively, "hand rolled" a circular buffer. This change simply migrates directly to boost::circular_buffer.

[scottschurr]

I've not looked at the code. But I want to make sure you're aware that boost::circular_buffer is fixed size and (from the documentation)...

When its capacity is exhausted, newly inserted elements will cause elements to be overwritten, either at the beginning or end of the buffer (depending on what insert operation is used).

If you're okay with that in this particular application then change ahead. I've never found a place where these characteristics are useful. I always want to know when overflow occurs. I never want the buffer to silently do the wrong thing.

[nbougalis]

Appreciate the heads up @scottschurr. Yeah, this is the right thing in this instance and it is, in fact, what the code was already doing: if the deque was "full" (i.e. contained a given number of items), pop the front and then push the new item to the tail. The very definition of a circular buffer.

[cjcobb23]

I'm wondering why this comment is here. It seems that circular_buffer is the obvious choice here, so I'm wondering why Vinny was suggesting a sorted vector.

[nbougalis]

We use std::find in a few places, so a sorted vector would make it possible to use std::binary_search instead of std::find.

It would trade additional insertion complexity for fewer comparisons during a search. I don't know how this comes down.

[HowardHinnant]

I've done a few studies on this and it depends on the length of the sequence, complexity of the comparison operator and size of each element. But the takeaway is that if sizeof and comparison are fairly cheap, the linear search wins for a surprising length. I don't have the exact numbers off the top of my head, but I believe it was in the hundreds, not in the tens, before binary search began to win.