|
Boost : |
From: John E. Potter (jpotter_at_[hidden])
Date: 2001-08-10 14:22:43
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.
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk