The invalid iterator checking in the circular_buffer library is
excessively strict. It checks not when an iterator is dereferenced, but whenever any operator involving that iterator is used.

I have an class defined to keep the last few data points, up to either a maximum number, or some condition on the stored data (e.g. the sum must be below a threshold) is met. So I figured I'd store the data in a circular buffer, and push new data onto the front, and store my own
iterator into it to use as the end.

If my end iterator is pointing to the next to last element in the
buffer, when a new item is pushed onto the front of the circular buffer, that iterator becomes invalid. But that's not a problem for me, because I don't read past it. _Except_ the validity of the iterator is checked even when using it in operator== (and other iterator comparison operators), so my lopp condition tests now throw because the end of my ranges are no longer valid.

Why isn't iterator invalidation only checked on dereferencing?

Is there any suggested convention for changing my code to work under
debug? I would try checking for BOOST_CB_ENABLE_DEBUG and catching these cases before the push_front occurs, but that macro is undefined at the end of the header. Or I could try something more complicated without the macro check, such as storing my ends in reverse iterators, and converting them whenever I need to do comparisons, though that is rather painful.

I've attached a simple example which demonstrates the problem, not that
it fails when the distance from my_end to end and the next element is
pushed into the front.

--
Anthony Foglia
Princeton Consultants
(609) 987-8787 x233