[ 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.