Boost logo

Boost :

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

istream_iterator i(cin), j;
++i; // make sure we've actually read a value from the stream
j = i;
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...


Boost list run by bdawes at, gregod at, cpdaniel at, john at