istream::peek curious behavior wrt. EOF

问题

I've just encountered a curious situation in C++. I was doing something like:

istream in;
// ...
in.get();      // get a char (which turns out to be the last)
               // curiously ios::eof bit doesn't get set just yet

c = in.peek(); // attempt to peek, return EOF and now set ios::eof bit

if(c == EOF) {
    // realize shouldn't have gotten the last char for some reason
    in.unget(): // attempt to unget, *fails* (because ios:eof bit was set)
}

Now I'm curious why peek sets the eof bit; I find this highly unintuitive. It's supposed to just peek not actually consume anything and shouldn't change the stream state. Also, why unget subsequently doesn't work? Does the standard mandates all operations to be nop when good() is false or something?

回答1:

in.get();      // get a char (which turns out to be the last)
               // curiously ios::eof bit doesn't get set just yet

This is not "curious". The stream's EOF bit gets set when a read fails due to having reached eof; it does not mean "the last read took us to eof".

c = in.peek(); // attempt to peek, return EOF and now set ios::eof bit

Like now.

Also, why unget subsequently doesn't work? Does the standard mandates all operations to be nop when good() is false or something?

... which is what's happening. You failed to otherwise define "doesn't work".

You'll have to clear the stream's state yourself when EOF was reached, if you want to unget that character you retrieved on line 3.

istream in;
// ...
in.get();      // assume this succeeds (*)

c = in.peek(); // assume this fails and sets EOF bit

if (!in) {
   in.clear(); // clear stream error state for use
   in.unget(); // "put back" that character (*)
}
else {
   // next char from .get() will be equal to `c`
}

来源：https://stackoverflow.com/questions/8763720/istreampeek-curious-behavior-wrt-eof

标签

c++

stream

eof

istream