stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: another istream_iterator question
Date Thu, 07 Feb 2008 22:35:18 GMT
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),
>>     }
>> 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:


View raw message