
Boost : 
From: Douglas Gregor (gregod_at_[hidden])
Date: 20010810 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk