Re: [boost] (infinite) sequences using recurrence relations

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-08-10 14:54:58

On Friday 10 August 2001 03:22, you wrote:
> On Fri, 10 Aug 2001, Douglas Gregor wrote:
> > Then how does the condition: "a == b and (a, b) in the domain of ==
> > implies *a equivalent to *b" from Table 72 hold up for istream_iterators
> > or istreambuf_iterators?
> >
> > istream_iterator i(cin), j;
> > ++i; // make sure we've actually read a value from the stream
> > j = i;
> > ++j;
> > if (i == j) // true, because they reference the same stream
> >   assert(*i == *j); // not necessarily so
> >
> > This will compile happily, run, and fail at the assertion, and yet my
> > fire extinguisher remains untouched...
>
> For input iterators in general, i and j are not in the domain of
> operator== because incrementing j invalidated i and it produced
> undefined behavior.  For istream_iterator in particular, there is
> a defect in the standard if the specification for operator==
> defines the domain.  That's what happens when an implementation is
> used as the basis for standardization.

Equality is defined, but not in a way that the domain is considered. For two 
istream_iterators, they are equal if neither is at the end and they reference 
the same stream. In the above code they aren't in the same domain (domain is 
left completely undefined for istream_iterator and istreambuf_iterator; I've 
been trying to discern what the domain is so I can justify the notion of 
"equivalence" from table 72). I don't think any of this qualifies as a 
defect, but perhaps a description of the domain of operator== for each of the 
input iterators would suffice; then perhaps standard library implementors 
could introduce assertions to validate the domain, as in your code below.

> I would be quite happy with the domain being at least one end iterator
> and at most one non end iterator.
>
> bool operator== (istream_iterator<T> lhs, istream_iterator<T> rhs) {
>    if (! lhs.end() && ! rhs.end())
>       throw domain_error();
>    return lhs.end() && rhs.end();
>    }
>
> John

operator== must be reflexive, but otherwise I would _much_ prefer this 
constraint to the current specification.

        Doug