Tomas Puverle skrev:
Thorsten,
Thanks for the reply. See comments inline.
The change has happened long ago. It was a design mistake to try to make a range of singular iterators valid since it adds overhead also for those that don't need it.
When you say "overhead", are you speaking of size or speed? Was this overhead demonstrated by some particular use case? Does this mean you may be also removing the "singular" flag at some point?
Its only there in debug builds.
Is there a supported way of constructing valid empty ranges? I can't see that there's a way to do it.
Your use-case is new to me, but seems quite ok. But making boost::iterator_range as a mixture of a range and boost.optional seems like a bad idea.
I feel that by the same token, you could say that a default constructed std::vector<T> is a bad idea. I really like using Boost.Range but I think this new behaviour is a big shortcoming. I also never saw any mention of these breaking changes on boost.devel...
template<class Range> void foo(boost::optional
r_) { if (r && !r_->empty()) {...} } might be an idea?
IMHO, this is obfuscated. There is a difference between an empty range and a range which is optional.
An there is a difference betweeen an empty range and a singular range. You can always add the extra state...just derive from iterator-range an implement it. If boost::iterator_range did it, there would be no way of getting rid of the overhead. -Thorsten