Nathan Ridge wrote:
c) shouldn't there be:
template<ForwardIteratorRange> class forward_iterator_range { ... };
...
template<RandomIteratorRange> class random_access_iterator_range : public { size_type size() const; };
...
Wouldn't restructuring interator_range along the lines of the above resolve all the confusion here?
Robert Ramey
It would solve Jonathan's problem, sure.
But it would also hurt people who are trying to use iterator_range to package a pair of arbitrary iterators in generic code (which IMO is one of iterator_range's major use cases), because they would now have to use different classes for different types of iterators.
But doesn't the caller know the concept which his iterator pair models? Hmmm - different subject - when I think about it, it would seem to be that the ForwardIteratorRange concept should in fact support size() since this is easily implementable (albeit inefficiently so). I believe that this would also address the original question. But what really bugs me about the proposal is that it introduces hidden non-obvious behavior. I might invoke size() where it seems "obvious" that it should work and then something else happens because of SFINAE. The current situation where one does something "obvious" but wrong traps with a fault is far superior. I would say that boost in general has too much code which is smarter than the programmer calling it. This makes for surprising behavior which is hard to track down. Robert Ramey
Regards, Nate
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost