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

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

Answer 2

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 3

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 4

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

Press any key to continue . . .

message.

Answer 5

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 6

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 7

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 8

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 9

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...

Answer 10

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

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

Answer 11

You can specify that the executable is a Console app, not a Windows app, at least in VS2017. This makes your application run in a "Microsoft Visual Studio Debug Console", with "Press Any Key To Close This Window" appearing at the end of the console output:

Right click the project to bring up Properties.

Linker > System > Subsystem > Select "Console".

Press Apply before closing.