Martin Sebor wrote:
Mark Brown wrote:
I have been looking at the istream_iterator class, mostly out of
curiosity than to try to fix a specific bug, to see if there are
any other discrepancies with the standard and operator++ caught
my attention. The standard says that the operator should return
*in_stream >> value but the stdcxx definition looks like this:
istream_iterator& operator++ () {
return _C_strm && !!*_C_strm && (*_C_strm >> _C_val), *this;
}
There are two extra checks that aren't required by the standard.
They are probably harmless but I wonder if they shouldn't be
removed for efficiency. Does anyone see a problem with such
a change?
I see no problem with it. We should assert that _C_strm is non-null
before dereferencing it but other than that I see no reason to try
to prevent undefined behavior (the effects of operator++ are
undefined once the iterator has reached the end of the sequence).
I had a change of heart on this. IMO, istream_iterator is more
likely to be used by novices than by more experienced programmers
(because of its limited error checking and reporting), and so it
should be more user-friendly than a more advanced facility might
need to be. So having it work a little harder to avoid undefined
behavior (crashes or aborts) seems worth the user experience. So
that's what I implemented in my fix for STDCXX-645:
http://svn.apache.org/viewvc?view=rev&revision=619228
Martin
