C ++：cin.peek（），cin >> char，cin.get（char）

Question

I've got this code with use of cin.peek() method. I noticed strange behaviour, when input to program looks like qwertyu$[Enter] everything works fine, but when it looks like qwerty[Enter]$ it works only when I type double dollar sign qwerty[Enter]$$ . On the other hand when I use cin.get(char) everything works also fine.

#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

It's because your program won't get input from the console until the user presses the ENTER key (and then it won't see anything typed on the next line until ENTER is pressed again, and so on). This is normal behavior, there's nothing you can do about it. If you want more control, create a UI.

Answer 2

Honestly I don't think the currently accepted answer is that good.

Hmm looking at it again I think since, operator<< is a formatted input command, and get() a plain binary, the formatted version could be waiting for more input than one character to do some formatting magic.

I presume it is way more complicated than get() if you look what it can do. I think >> will hang until it is absolutely sure it read a char according to all the flags set, and then will return. Hence it can wait for more input than just one character. For example you can specify skipws .

It clearly would need to peek into more than once character of input to get a char from \\t\\t\\t test .

I think get() is unaffected by such flags and will just extract a character from a string, that is why it is easier for get() to behave in non-blocking fashion.

The reason why consider the currently accepted answer wrong is because it states that the program will not get any input until [enter] or some other flush-like thing. In my opinion this is obviously not the case since get() version works. Why would it, if it did not get the input?

It probably still can block due to buffering, but I think it far less likely, and it is not the case in your example.