Re: end of stream for std::cin
On Feb 22, 10:32 pm, Sanyi <Sandor.Benc...@gmail.com> wrote:
On Feb 22, 10:50 pm, James Kanze <james.ka...@gmail.com> wrote:
On Feb 22, 2:20 pm, Sanyi <Sandor.Benc...@gmail.com> wrote:
What is cin's streambuffer's state and content after the following
(using namespace std)?
string((istreambuf_iterator<char>(cin)),
istreambuf_iterator<char>()) );
I am trying to use this in a loop (to get a 'multiple cat'-like
behavior) and the second time around it returns an empty string
instead of waiting for more input.
And once a read has failed, the istream remains in failed
state until you clear the error.
This is not correct.
It's what the standard says, and what all conformant
implementations do.
When working with the streambuf directly, the
stream's state flags do not get set.
Obviously, since there is no stream.
So my comment concerning istream isn't relevant to the example.
Sorry about that.
Just to be sure, I checked, and cin itself is still in a good
state after the read. For the same reason cin.clear() will
not work.
What more input do you expect? It's easy to clear the
failbit: cin.clear(). But you're still at end of file, and
there is nothing more to read.
Huh? We are talking about the console input here.
Are we? I thought we were talking about cin. Which may or may
not be console input.
Last time I checked, when I pressed ^D, my keyboard did not
disappear in a cloud of smoke, neither did it refuse to accept
any more input.
Last time I checked on a Windows machine, if I pressed ^D, my
program read a ^D.
Under Unix, the convention is that ^D will terminate any read
(system level) in progress, immediately. (That's not actually
true, since you can easily configure this to be any character
you want. But ^D is the default.) Under Unix, the convention
is also that a system level read which returns 0 bytes read is
an end of file. Period. A well written filebuf which reads 0
bytes will set an internal flag, and always return EOF
afterwards. (Note that the conventions under Windows are very
different: a ^Z in a text file IS end of file. Period. In
every text file, not just console input, and regardless of where
it appears, even in the middle of a line.)
The standard is somewhat vague about this, but in practice, if
anything is to work, any calls to streambuf::sgets() without an
intervening streambuf::sbumps() or streambuf::snexts() must
return the same value. And this means that the streambuf must
have internal state, and memorize the end of file.
(Pragmatically, I follow the rule "be liberal in what you
accept, conservative in what you require". My streambuf classes
do memorize end of file, even if they are filtering streambuf's,
and get it from another streambuf. And my >> operators make a
point of never calling any of the read functions of streambuf
once I've seen EOF---and set eofbit---just in case the streambuf
doesn't use a flag. Experience with a number of different
implementations of iostream have lead me to be very cautious
about such things.)
It is also easy to imagine a similar need with files, say in a
log-file monitoring program. In one read pass I might reach
the end-of-file, but by the next pass some external process
might have added to it. End of file is not end of life.
No, but it is a definite state for a stream. The C++ I/O model
doesn't take into account the fact that file data might change
while the file is being read.
Of course, a specific implementation might offer additional
functions to reset this sort of state (and clear the
buffer---other processes might write into the middle of a file
as well), forcing the filebuf to retry next time around. But
it's very implementation dependent.
If you're really only concerned with Unix, the obvious solution
is to open "/dev/tty" each time. But such an interface
definitly conflicts with the Unix conventions, where the user
expects a ^D at the start of a line to be treated as an end of
file, with no more input coming from the console.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34