Sign in to follow this  
orcfan32

cin.get()

Recommended Posts

cin.get() returns one character(char) from the keyboard.


#include <iostream>

using namespace std;

int main( ){
unsigned char Key=0;
Key=cin.get(); // or cin.get(Key);
cin.get(); // for enter
cout << "User pressed key: " << Key << " ASCII: " << long(Key) << "\n";
cout << "Press any key to continue.";
cin.get(); // pause until key press, do not store return value
return 0;}



For some reason you must press enter before cin.get() exits which seems silly since it's only used to store one key.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
cin.get() is a litle like Sleep() in other languages, without cin.get() the program would just start and close...

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
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

myprogram
pause


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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this