C++：cin.peek()，cin >> char，cin.get(char)

Question

我使用cin.peek()方法得到了这段代码。我注意到奇怪的行为，当程序的输入看起来像qwertyu$[Enter]时，一切正常，但当它看起来像qwerty[Enter]$时，它只有在我输入双美元符号qwerty[Enter]$$时才起作用。另一方面，当我使用cin.get(char)时，一切都很好。

#include <iostream>
#include <cstdlib>

using namespace std;



int main()
{
char ch;
int count = 0;

while ( cin.peek() != '$' )
{
    cin >> ch;         //cin.get(ch);
    count++;
}

cout <<  count << " liter(a/y)\n";

system("pause");
return 0;
}


//Input:
// qwerty$<Enter>  It's ok
//////////////////////////
//qwerty<Enter>
//$                Doesn't work
/////////////////////////////
//qwerty<Enter>
//$$                 works(?)

Answer 1

这是因为在用户按ENTER键之前，您的程序不会从控制台获得输入(然后在再次按ENTER键之前，它不会看到下一行中键入的任何内容，依此类推)。这是正常行为，你对此无能为力。如果您想要更多的控制，请创建一个UI。

Answer 2

老实说，我不认为目前被接受的答案是那么好。

嗯，再看一遍，我想既然operator<<是一个格式化的输入命令，而get()是一个普通的二进制文件，那么格式化的版本可能需要等待比一个字符更多的输入才能完成一些格式化魔术。

我假设它比get()复杂得多，如果你看看它能做什么的话。我认为>>将挂起，直到它完全确定它根据所有设置的标志读取了char，然后将返回。因此，它可以等待更多的输入，而不仅仅是一个字符。例如，您可以指定skipws。

显然，它需要多次查看输入字符才能从\t\t\t test获得char。

我认为get()不会受到这些标志的影响，只会从字符串中提取一个字符，这就是为什么get()更容易以非阻塞的方式运行。

之所以认为当前接受的答案是错误的，是因为它声明程序在[enter]或其他类似刷新的东西之前不会得到任何输入。在我看来，这显然不是这种情况，因为get()版本可以工作。如果它没有得到输入，为什么要这样做呢？

它可能仍然会因为缓冲而阻塞，但我认为它的可能性要小得多，在你的例子中也不是这样的。