I was about to suggest that if you want to build a generic library that uses ranges, stick to the Range concepts (http://tinyurl.com/5z56n2) and avoid tying yourself to types generated from iterator_range. Tight bundling always causes problems like this. With concepts all of the constraints on a type can be encoded in a concept checking class and automatically verified at compile time (and of course proposed C++0x language extensions could make this even easer/cleaner). Users can rely on the concepts being implemented, and authors can use concept checks to make sure their implementations meet user expectations.
Daniel, Thank you for the insightful post. I will change my code to be more in conformance with the range concept rather than with the iterator_range implementation. However, this will still not solve the problem for my users. Even if I make the relevant changes and my users still pass in a default constructed iterator_range, boost::begin() == boost::end() will not work, because iterator_range asserts on the range not being singular in almost all of the member functions. This means that I need to erradicate this class altogether.
If you don't pass the test, change the test?!!!
I am sorry to hear this is the case. Tom