iterator_range's assignment fires an assert when rhs is singular

[eyal.farago@…]

the following code will raise an assertion in debug builds:

typedef boost::iterator_range<std::string> str_range_t;

std::string eyal("eyal");
str_range_t eyal_range( eyal ), empty_range;

//here it is...
eyal_range = empty_range;

the reason for the assert is an assert in iterator_range's begin/end methods, the assignment operator is doing something like

this->m_begin = rhs.begin()

which fails for debug builds when rhs is singular.

a lot has been said about the decision to remove the singular member/concept from the library code, but I believe that assigning a singular range should not raise an assert.

ps. I stumbled upon this bug after upgrading from 1.34 to 1.36, "I think this is a really nasty one because:

1. it denies me from using a very standard use case.
   
2. it simply crashes in release builds.
   
3. a massive behavior change for singular ranges which used to behave like empty ranges. while I agree that using iterators of a singular range is a bad idea, querying for its length is not.
   

eyal.

[Neil Groves]

The submitted code should never have compiled since iterator_range<std::string> is illegal.

The newly merged RangeEx into Range runs the following code without assertion in debug, or crash in release.

I made the decision to remove the singularity concept from Boost.Range entirely. It is my opinion that singularity is a property of iterators and that it is not possible to usefully augment range to provide additional safety without removing the capability to support valid use-cases.

#include <string> #include <boost/range/iterator.hpp> #include <boost/range/sub_range.hpp>

typedef boost::sub_range<std::string> str_range_t;

int main(int argc, const char* argv[]) {

std::string eyal("eyal"); str_range_t eyal_range( eyal ), empty_range;

eyal_range = empty_range;

return 0;

}