[Boost-users] circular_buffer, debug and invalid iterator checking

Subject: [Boost-users] circular_buffer, debug and invalid iterator checking
From: Anthony Foglia (afoglia_at_[hidden])
Date: 2010-11-05 21:17:27

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
[phone] x233