istream :: peek好奇行为wrt。 EOF

Question

我刚刚在C ++中遇到了一个奇怪的情况。 我正在做类似的事情：

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)
}

现在我很好奇为什么peek设置了eof位； 我觉得这很不直观。 它应该只是偷看实际上没有消耗任何东西，并且不应该更改流状态。 另外，为什么后来unget却不起作用？ 当good()为false或类似的东西时，该标准是否要求所有操作均为nop？

Answer 1

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

这不是“好奇”。 当由于达到eof而导致读取失败时，流的EOF位置1。 但这并不意味着“最后一次读取带我们到EOF”。

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

像现在。

另外，为什么后来unget却不起作用？ 当good()为false或类似的东西时，该标准是否要求所有操作均为nop？

...这是怎么回事。 您未能以其他方式定义“无效”。

如果要unget在第3行检索到的字符，则必须在到达EOF时unget清除流的状态。

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`
}