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

Hi Antony, If you a problem only with iterator invalidation (which works in debug mode only) you can disable it completely. The documentation says: The debug support is enabled only in the debug mode (when the NDEBUG is not defined). It can also be explicitly disabled (only for circular_buffer) by defining BOOST_CB_DISABLE_DEBUG macro. Regards, Jan On 6 Nov 2010, at 01:17, Anthony Foglia <afoglia@princeton.com> wrote: 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 <circular_buffer_test.cpp> _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Jan Gaspar wrote:
If you a problem only with iterator invalidation (which works in debug mode only) you can disable it completely. The documentation says: The debug support is enabled only in the debug mode (when the NDEBUG is not defined). It can also be explicitly disabled (only for circular_buffer) by defining BOOST_CB_DISABLE_DEBUG macro.
How would that work is my code is linked with other code that doesn't turn off the BOOST_CB_DISABLE_DEBUG macro? I would imagine there would only be a problem if some other code is using a circular buffer to hold the same type I am (which is probably the case, but puts a requirement on other people's code). Is that it? -- Anthony Foglia Princeton Consultants (609) 987-8787 x233

Hi Antony, unfortunatelly yes. The other code has to be compiled with BOOST_CB_DISABLE_DEBUG defined as well if it is using a circular_buffer which holds the same type. Jan ________________________________ From: Anthony Foglia <AFoglia@princeton.com> To: boost-users@lists.boost.org Sent: Mon, 8 November, 2010 15:34:28 Subject: Re: [Boost-users] circular_buffer, debug and invalid iterator checking Jan Gaspar wrote:
If you a problem only with iterator invalidation (which works in debug mode only) you can disable it completely. The documentation says: The debug support is enabled only in the debug mode (when the NDEBUG is not defined). It can also be explicitly disabled (only for circular_buffer) by defining BOOST_CB_DISABLE_DEBUG macro.
How would that work is my code is linked with other code that doesn't turn off the BOOST_CB_DISABLE_DEBUG macro? I would imagine there would only be a problem if some other code is using a circular buffer to hold the same type I am (which is probably the case, but puts a requirement on other people's code). Is that it? -- Anthony Foglia Princeton Consultants (609) 987-8787 x233 _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (2)
-
Anthony Foglia
-
Jan Gaspar