cin.get()
cin.get() returns one character(char) from the keyboard.
For some reason you must press enter before cin.get() exits which seems silly since it's only used to store one key.
#include <iostream>using namespace std;int main( ){unsigned char Key=0;Key=cin.get(); // or cin.get(Key);cin.get(); // for entercout << "User pressed key: " << Key << " ASCII: " << long(Key) << "\n";cout << "Press any key to continue.";cin.get(); // pause until key press, do not store return valuereturn 0;}For some reason you must press enter before cin.get() exits which seems silly since it's only used to store one key.
I used it a couple of times to keep the console window up so it wouldn't just flash then go away before I could see the input and output on the screen.
cin.get() is a litle like Sleep() in other languages, without cin.get() the program would just start and close...
Quote:Original post by SKATIN_HARD
I used it a couple of times to keep the console window up so it wouldn't just flash then go away before I could see the input and output on the screen.
You should use cin.ignore for that, since you don't really want to get input, just to wait for a pressed key. cin.get(can have parameters)
The .get() method of any input stream will take the next character off the stream and return it.
By default, the console-associated streams (cin, cout, cerr, clog, and the wide-char variants if appropriate) are "line buffered"; when you type at the console, nothing actually gets stuck into the cin "available" buffer until the end of the line, at which point all of that line becomes available to be read. Thus, if you invoke cin.get() at a time when everything has been read so far, the program will "block" (suspend while waiting for the IO request to complete) until return is hit.
There are a lot of other ways to accomplish the same effect, too. But I'm not going to go into them, because:
Generally, it's a bad idea to artificially pause a program at the end - in any way. A command-line program should normally be run from the command line, which implies that the window would not disappear at program end - it would just go back to the prompt. If you really want to be able to double-click something, have the program run and then make sure that the user gets to see a "goodbye" message, you can wrap the program execution in a batch file:
// myprogram.bat
This is more flexible (you can always put other stuff in the batch file instead without needing to recompile, and command line users don't have to deal with an extra useless prompt - an especially annoying one if you already have a main menu where you have to press 'q' to quit or something), and also gives the job of launching programs to the command shell (the rightful owner of that task) rather than another program.
It's also "thread-safe" (I guess this isn't the usual meaning of the term though) : blocking I/O only blocks the thread that makes the IO request, but the batch file will always work because pause isn't invoked until after the program has already exited and all threads are dead.
By default, the console-associated streams (cin, cout, cerr, clog, and the wide-char variants if appropriate) are "line buffered"; when you type at the console, nothing actually gets stuck into the cin "available" buffer until the end of the line, at which point all of that line becomes available to be read. Thus, if you invoke cin.get() at a time when everything has been read so far, the program will "block" (suspend while waiting for the IO request to complete) until return is hit.
There are a lot of other ways to accomplish the same effect, too. But I'm not going to go into them, because:
Generally, it's a bad idea to artificially pause a program at the end - in any way. A command-line program should normally be run from the command line, which implies that the window would not disappear at program end - it would just go back to the prompt. If you really want to be able to double-click something, have the program run and then make sure that the user gets to see a "goodbye" message, you can wrap the program execution in a batch file:
// myprogram.bat
myprogrampauseThis is more flexible (you can always put other stuff in the batch file instead without needing to recompile, and command line users don't have to deal with an extra useless prompt - an especially annoying one if you already have a main menu where you have to press 'q' to quit or something), and also gives the job of launching programs to the command shell (the rightful owner of that task) rather than another program.
It's also "thread-safe" (I guess this isn't the usual meaning of the term though) : blocking I/O only blocks the thread that makes the IO request, but the batch file will always work because pause isn't invoked until after the program has already exited and all threads are dead.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
