From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-08-10 13:32:52
On Friday 10 August 2001 02:17, you wrote:
> On Fri, 10 Aug 2001, Corwin Joy wrote:
> > Still, the way the standard
> > defines equality for
> > input iterator bugs me then since it seems to me that if (i, j) is not in
> > the domain of == the operator
> > should return false rather than returning true just because (i, j) point
> > to the same stream.
>
> Err, if (i, j) is not in the domain of ==, your computer should catch
> fire when you test it.
>
> Operator== is an equivalence relation. For istream_iterators, not
> input iterators in general, the domain is iterators into a stream
> and the end of stream iterator. The equalalence classes are the
> end of stream iterator and other streams iterator. For istreambuf
> iterators, there are only two equivalence classes. IMO, that is
> overspecified. Algorithms operate on iterator ranges. The only
> requirement from the algorithms is that two end of stream iterators
> compare equal and that a non end of stream iterator not compare
> equal to an end of stream iterator. There is no use for a comparison
> of two non end input iterators.
>
> John
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...
Doug