Andrew, On Tue, Nov 25, 2008 at 4:07 PM, Andrew Sutton <andrew.n.sutton@gmail.com>wrote:
I think this is the right answer (and pretty well argued by now). The
behavior of the iterator_range should "inherit" (is there a better word for this?) its semantics from the underlying iterator. To do otherwise would impose requirements on iterators that may not (easily) support those semantics, making the concept less generic (as in represents fewer possible implementations).
Well, it is fairly easy to remove some of the debug-checks from the code. Do I understand you correctly in that you want them all removed?
No! Definitely no. As I understand it, those debug checks are kind of playing the role of axiomatic preconditions in debug mode, so they're actually reinforcing the correct behavior. I think.
Yes! Definately yes ;-) The checks have all manner of false-positives. They aren't axiomatic preconditions that should apply for all or even most iterator types used with iterator_range. The iterator_range simply cannot reliably determine if the iterator is invalid due to it being singular. Singularity is a property of iterators. If singulairity requires additional debugging infrastructure it should be added to a debugging iterator framework. It's far too restricting upon the typical and valid usages of iterator_range.
I think from a previous post I was considering a kind of checked iterator_range that could provide additional diagnostics in debug mode - something akin to the STLPort checked iterators. Providing something like that as a compile-time replacement for iterator_range would free that class up to be as lean as possible and sans preprocessor. Completely outside the scope of the discussion... sorry.
Andrew Sutton andrew.n.sutton@gmail.com
Neil Groves
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost