[ 
https://issues.apache.org/jira/browse/STDCXX-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557536#action_12557536
 ] 

Martin Sebor commented on STDCXX-645:
-------------------------------------

I've been looking into this and I think either there's a real issue in the 
standard or the text is confusing. My post on the subject to the committee's 
list is below. The confusing part is that [istream.iterator], p1, duplicates a 
couple of preconditions for istream_iterator operations (operator*() and 
operator->()) from Table 96, Input Iterator Requirements, but not others, 
notably operator++(). This could mean that istream_operator::operator++() is 
well-defined for end-of-stream iterators or it could be just another piece of 
redundant text in the standard...

-------- Original Message --------
Subject: can an end-of-stream iterator become a non-end-of-stream one?
Date: Wed, 09 Jan 2008 16:08:52 -0700
From: Martin Sebor <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Organization: Rogue Wave Software, Inc.
To: undisclosed-recipients:;

To: C++ libraries mailing list
Message c++std-lib-20003

The istream_iterator description says that "If the end of stream is
reached (operator void*() on the stream returns false), the iterator
becomes equal to the end-of-stream iterator value" without explaining
how exactly this is done.

One possible approach used in practice is for the iterator to set its
in_stream pointer to 0 just like the default ctor does. The problem
with this approach is that the Effects clause for operator++() says
the iterator unconditionally extracts the next value from the stream
by evaluating:

    *in_stream >> value;

This can be easily detected by a program setting eofbit or failbit
in exceptions of the associated stream and iterating past the end
of the stream (each past-the-end read should trigger an exception).

Another approach, one that would allow operator++() to attempt to
extract the value even for end-of-stream (EOS) iterators (just as
long as in_stream is non-0) is for the iterator to maintain a flag
indicating whether it has reached the end of the stream. This
approach, however, even though it's also used in practice, isn't
supported by the exposition-only members of the class (no such flag
is shown).

The question then: Is it the intent that a non-EOS that has reached
the EOS become a non-EOS one again after the stream's eofbit flag
has been cleared? I.e., are the assertions in the program below
expected to pass?

    sstream strm ("1 ");
    istream_iterator eos;
    istream_iterator it (strm);
    int i;
    i = *it++
    assert (it == eos);
    strm.clear ();
    strm << "2 3 ";
    assert (it != eos);
    i = *++it;
    assert (3 == i);

Or is it intended that once an iterator becomes EOS it stays EOS until
the end of its lifetime?

Martin


> stream iterators into different streams compare equal
> -----------------------------------------------------
>
>                 Key: STDCXX-645
>                 URL: https://issues.apache.org/jira/browse/STDCXX-645
>             Project: C++ Standard Library
>          Issue Type: Bug
>          Components: 24. Iterators
>    Affects Versions: 4.1.3, 4.2.0
>            Reporter: Mark Brown
>
> As Travis says in his reply to my post here:
> http://www.nabble.com/stream-iterators-into-different-streams-compare-equal--tf4721505.html#a13498487:
>     Given 24.5.1.1 p1 and p2, it is pretty clear to me that the two iterators 
> are both non-end-of-stream type, and they are both created on different 
> streams. The streams are different, so the iterators should not compare 
> equal. I guess one could claim that 24.5.1.2 p6 conflicts with 24.5 p3 
> because 'end-of-stream' isn't clearly defined, but in this particular case 
> that doesn't matter.
> This program aborts with stdcxx but not with gcc:
> #include <assert.h>
> #include <iterator>
> #include <sstream>
> int main ()
> {
>     std::istringstream a ("1");
>     std::istream_iterator<int> i (a);
>     std::istringstream b ("2");
>     std::istream_iterator<int> j (b);
>     assert (!(i == j));
> } 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to