If I may ramble philosophically for a minute, most of the approaches shown here are bad. Oh, sure, they give you the desired effect, but they're still bad.

Why?

So you have a program that performs an action. You test the program from within your IDE, and it flashes momentarily. Now, the program is actually designed to be run from the command line. If you modify the program to wait for an additional keypress so that you can see its output when run from the IDE, then when you run it from the command line it will still wait for that keypress - without prompting the user. Even if you prompt the user, you're only adding an unnecessary hinderance to its normal use.

Good IDEs recognize this, so they automatically launch command line projects within a "shell" of sorts that waits for a keypress to close. This means you don't have to modify the behavior of your program to quickly test it from within your IDE, which is good. Since you appear not to have a good IDE, the proper solution is to have a command console open and set to the binary output directory from which you can run the program manually.

Since that is inconvenient, however, people will continue to use getch, kbhit, cin, system("pause") and all other such hacks. That's fine. The whole point of my philosophical rambling is so that you'll know when to remove such code, and why, and so that you'll know how to fix errant behavior if you happen to run your program from the command line.

Happy hacking!

Please no hacks. Just run it from the command line.

Quote:Original post by Oluseyi
If I may ramble philosophically for a minute, most of the approaches shown here are bad. Oh, sure, they give you the desired effect, but they're still bad.

Why?

So you have a program that performs an action. You test the program from within your IDE, and it flashes momentarily. Now, the program is actually designed to be run from the command line. If you modify the program to wait for an additional keypress so that you can see its output when run from the IDE, then when you run it from the command line it will still wait for that keypress - without prompting the user. Even if you prompt the user, you're only adding an unnecessary hinderance to its normal use.

Good IDEs recognize this, so they automatically launch command line projects within a "shell" of sorts that waits for a keypress to close. This means you don't have to modify the behavior of your program to quickly test it from within your IDE, which is good. Since you appear not to have a good IDE, the proper solution is to have a command console open and set to the binary output directory from which you can run the program manually.

Since that is inconvenient, however, people will continue to use getch, kbhit, cin, system("pause") and all other such hacks. That's fine. The whole point of my philosophical rambling is so that you'll know when to remove such code, and why, and so that you'll know how to fix errant behavior if you happen to run your program from the command line.

Happy hacking!

Agreed 100%, and AFAIK Fruny agrees too. Can we please put this in the FAQ?

use

system("pause");

ive used it and its much better then these getch and shit... good luck

There are a few ways to do this; I sometimes put a breakpoint on the last instruction in the main function.

my guess is you are using Microsoft Visual Studio? use the debug option. (f5 I think).