This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++11 status.
Section: 25.6.4 [istreambuf.iterator] Status: C++11 Submitter: Niels Dekker Opened: 2007-03-25 Last modified: 2016-01-28
Priority: Not Prioritized
View other active issues in [istreambuf.iterator].
View all other issues in [istreambuf.iterator].
View all issues with C++11 status.
Discussion:
Greg Herlihy has clearly demonstrated that a user defined input iterator should have an operator->(), even if its value type is a built-in type (comp.std.c++, "Re: Should any iterator have an operator->() in C++0x?", March 2007). And as Howard Hinnant remarked in the same thread that the input iterator istreambuf_iterator doesn't have one, this must be a defect!
Based on Greg's example, the following code demonstrates the issue:
#include <iostream>
#include <fstream>
#include <streambuf>
typedef char C;
int main ()
{
std::ifstream s("filename", std::ios::in);
std::istreambuf_iterator<char> i(s);
(*i).~C(); // This is well-formed...
i->~C(); // ... so this should be supported!
}
Of course, operator-> is also needed when the value_type of istreambuf_iterator is a class.
The operator-> could be implemented in various ways. For instance, by storing the current value inside the iterator, and returning its address. Or by returning a proxy, like operator_arrow_proxy, from http://www.boost.org/boost/iterator/iterator_facade.hpp
I hope that the resolution of this issue will contribute to getting a clear and consistent definition of iterator concepts.
[ Kona (2007): The proposed resolution is inconsistent because the return type of istreambuf_iterator::operator->() is specified to be pointer, but the proposed text also states that "operator-> may return a proxy." ]
[ Niels Dekker (mailed to Howard Hinnant): ]
The proposed resolution does not seem inconsistent to me. istreambuf_iterator::operator->() should have istreambuf_iterator::pointer as return type, and this return type may in fact be a proxy.
AFAIK, the resolution of 445 ("iterator_traits::reference unspecified for some iterator categories") implies that for any iterator class Iter, the return type of operator->() is Iter::pointer, by definition. I don't think Iter::pointer needs to be a raw pointer.
Still I wouldn't mind if the text "operator-> may return a proxy" would be removed from the resolution. I think it's up to the library implementation, how to implement istreambuf_iterator::operator->(). As longs as it behaves as expected: i->m should have the same effect as (*i).m. Even for an explicit destructor call, i->~C(). The main issue is just: istreambuf_iterator should have an operator->()!
[ 2009-04-30 Alisdair adds: ]
Note that operator-> is now a requirement in the InputIterator concept, so this issue cannot be ignored or existing valid programs will break when compiled with an 0x library.
[ 2009-05-29 Alisdair adds: ]
I agree with the observation that in principle the type 'pointer' may be a proxy, and the words highlighting this are redundant.
However, in the current draught pointer is required to be exactly 'charT *' by the derivation from std::iterator. At a minimum, the 4th parameter of this base class template should become unspecified. That permits the introduction of a proxy as a nested class in some further undocumented (not even exposition-only) base.
It also permits the istream_iterator approach where the cached value is stored in the iterator itself, and the iterator serves as its own proxy for post-increment operator++ - removing the need for the existing exposition-only nested class proxy.
Note that the current proxy class also has exactly the right properties to serve as the pointer proxy too. This is likely to be a common case where an InputIterator does not hold internal state but delegates to another class.
Proposed Resolution:
In addition to the current proposal:
25.6.4 [istreambuf.iterator]
template<class charT, class traits = char_traits<charT> > class istreambuf_iterator : public iterator<input_iterator_tag, charT, typename traits::off_type,charT*unspecified, charT> {
[ 2009-07 Frankfurt ]
Move the additional part into the proposed resolution, and wrap the descriptive text in a Note.
[Howard: done.]
Move to Ready.
Proposed resolution:
Add to the synopsis in 25.6.4 [istreambuf.iterator]:
charT operator*() const; pointer operator->() const; istreambuf_iterator<charT,traits>& operator++();
25.6.4 [istreambuf.iterator]
template<class charT, class traits = char_traits<charT> >
class istreambuf_iterator
: public iterator<input_iterator_tag, charT,
typename traits::off_type, charT* unspecified, charT> {
Change 25.6.4 [istreambuf.iterator], p1:
The class template istreambuf_iterator reads successive characters from the streambuf for which it was constructed. operator* provides access to the current input character, if any. [Note: operator-> may return a proxy. — end note] Each time operator++ is evaluated, the iterator advances to the next input character. If the end of stream is reached (streambuf_type::sgetc() returns traits::eof()), the iterator becomes equal to the end of stream iterator value. The default constructor istreambuf_iterator() and the constructor istreambuf_iterator(0) both construct an end of stream iterator object suitable for use as an end-of-range.