You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Mark Brown <ma...@gmail.com> on 2007/11/03 18:32:03 UTC

another istream_iterator question

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?

--Mark

Re: another istream_iterator question

Posted by Martin Sebor <se...@roguewave.com>.
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


Re: another istream_iterator question

Posted by Martin Sebor <se...@roguewave.com>.
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).

Martin

> 
> --Mark
>