What is the Best Practice for Combating the Console Closing Issue?

Question

After compiling console programs the console window closes immediately after running. What is the best practice for keeping it open? I've searched google loads, I'm used to codeblocks where you don't have to worry about it, but, I want to mess around with Visual Studio a bit and with VS, my console closes. All over the interwebz there are several different ways to keep it open, however, I've read that most of them are bad coding techniques. What is everyones preferred method?

Answer 1

cin is grossly inelegant but easy for the forgetful to derive:

{ char c; std::cin >> c; }

That holds the window open until you type a character /* edit */ and hit enter.

std::cin.get() will close the window the moment you type a character, which, depending on how easily you become habituated, runs a marginally greater risk of "whoops, I wish I hadn't closed that!" than the two-keystroke operator>>(istream &).

Both differ from a system("pause") in that they return in a program-accessible way the value of the character you typed, so, if as not infrequently happens, one kludge leads to another, you can write a switch statement based on what you typed to (for example) exit immediately, write some values to a log, run it again, etc.

Answer 2

A very common one is to just put in code to read a key from the console after your main application code closes. The keystroke read in just gets thrown away, but it holds the console open.

It's not pretty, necessarily - but I often do this wrapped in a debug define, so during debugging, the console is held open. During release, I'm usually not running inside VS, and when run from a command line, this is no longer an issue.

Answer 3

Since you always run in the debugger, set a breakpoint on the return statement from main().

The debugger is your best friend, learn (and learn early) to use it to your advantage at every opportunity.

Answer 4

Run your program in a console, which would be the expected way of running a console program ...

Alternatively, you can make a little batch file to execute your program that would have:

REM batch file to launch program
yourprogram.exe
PAUSE

and the PAUSE cmd.exe command will ask to user to press any key.

Answer 5

I tend to use system("PAUSE"); which gives you a

Press any key to continue . . .

message.

Answer 6

Call this function before you return at the end of main:

void onEnd()
{
    printf("Press any key to exit...");
    _getch();
}

Answer 7

When I'm using Visual Studio and I don't need debugging I just running it using Ctrl-F5 keystroke - it prevents console from closing.

Answer 8

I use:

cin.get()

I heard it was less costly than system("PAUSE") and it works on POSIX systems too. There's a great link that goes into detail about this.

Answer 9

Resist the temptation to do anything. Well behaved command line programs exit when they've finished running reporting a status via their exit code. This enables them to be scriptable and 'good citizens' in automated environments. Even in an interactive environment, why force the user to make an extra key press just because of your debugging environment?

If you run, rather than debug then Visual Studio will open a console windows that pauses after your application exits so that you can still view the output. I don't know why the behaviour is different when you debug, perhaps because you have breakpoints available so if you want to see the output at various stages you can place breakpoints after the relevant output statements, or at the end of main or enable various 'stop on exception throw' options.

Whatever the reason, I've never felt compelled to compromise the behaviour of my application just to enhance my debugging experience.

Answer 10

The "don't do that" responses in this thread may seem curt, but they're fairly sensible. I happened across this question because I'm debugging a gtest suite that used to run fine, but now crashes mysteriously when launched. When run from the console, it pops up a dialog saying "blah.exe has stopped working"; but, when run from the debugger, the console pops up momentarily, vanishes, and the program exits with 0 status.

I should have been thinking about how odd this difference in behavior was, but instead I was like: "Aw, man---I gotta make that console window stay up so I can see what it says." Right?

It turns out that the machine I'm working on (a colleague of mine's) had the 'Command Arguments' for the debugger set to '--gtest_filter=*testMsg*'. I noticed this right away, too, but it never occurred to me that all the tests matching the filter had been renamed in a recent commit. So, when launched from the debugger, gtest wasn't finding any tests to run and was simply exiting. Another 90 minutes of my life I'll never get back. (-_-) I could have ditched this tar baby a lot sooner if my knee-jerk reaction hadn't been to think I needed that console window to stay open in order to solve the problem...