Re: [boost] Is Boost.Range broken?

Subject: Re: [boost] Is Boost.Range broken?
From: Scott McMurray (me22.ca+boost_at_[hidden])
Date: 2008-11-22 12:08:34

On Sat, Nov 22, 2008 at 09:13, Andrey Semashev
<andrey.semashev_at_[hidden]> wrote:
>
> With such a notion this, indeed, is a rather useless component. I have to
> agree with Tomas and others in one of their points: one of the major
> advantages or ranges before pairs of iterators is that they attempt to
> reproduce containers as far as possible. Yes, in general default-constructed
> iterators are singular and they cannot be used reliably. However, not all
> iterators behave that way. Pointers, for example, are NULL on
> default-initialization (which is used in the default constructor of the
> iterator_range class). I can well have my own iterators that are
> default-constructible and allow comparison in this state. And I don't
> understand why an iterator range of these iterators suddenly restricts me
> from being able to compare these iterators in empty(), for example.
>

I think you just raised the most important point in this thread.

iterator_range<ostream_iterator<string> >() is not singular, yet 1.37
will say it is, so that's clearly wrong.

But yet, the old way is also bad.

iterator_range<string::iterator>() was singular, with its empty()
returning true, while the conceptually equilavent
iterator_range<string::iterator>(string::iterator(),
string::iterator()), which is also singular, has an empty() that
invokes UB.

Also, what if I write a random_number_iterator, a forward iterator
which returns a different random number after each increment?  Then
iterator_range<random_number_iterator>() is again non-singular, and it
has an infinite size (operator== would always be false), so the
empty() for the range should *not* return false.

An iterator_range is just that, and trying to hide what it is seems
doomed to failure.

> The documentation of the iterator_range states for several functions, such
> as size() and operator[], that these functions depend on the iterator
> nature. I believe, empty() could just do the same - rely on the ability to
> compare iterators, even default-initialized ones. Of course, this should be
> clearly stated in the docs.
>

That is, as mentioned, precisely what has been stated in the docs
since at least 1_33_1.