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
>