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