C++: cin.peek(), cin >> char, cin.get(char)

C++: cin.peek(), cin >> char, cin.get(char)

本文关键字:cin gt char get peek C++      更新时间:2023-10-16

我使用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(?)

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

老实说,我认为目前接受的答案没有那么好。

嗯,再看一遍,我认为operator<<是一个格式化的输入命令,而get()是一个普通的二进制,格式化版本可能需要等待多个输入,而不是一个字符来实现一些格式化魔术。

如果你看看它能做什么,我认为它比get()复杂得多。我认为>>会挂起,直到它绝对确定根据设置的所有标志读取了char,然后才会返回。因此,它可以等待比一个字符更多的输入。例如,可以指定skipws

很明显,它需要窥视输入的不止一个字符,才能从ttt test获得char

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

之所以认为当前接受的答案是错误的,是因为它声明程序在[enter]或其他类似flush的东西之前不会得到任何输入。在我看来,由于get()版本有效,情况显然并非如此。如果它没有得到输入,为什么会这样做?

由于缓冲,它可能仍然会阻塞,但我认为这种可能性要小得多,而且在您的示例中并非如此。