C++ - Command prompt window in Visual Studio [duplicate]

This question already has answers here: Closed 12 years ago.

Possible Duplicate:

How to stop C++ console application from exiting immediately?

I've just started to use Visual Studio 2010 while learning C++. When I compile and run my code, I briefly see the command prompt appear on the screen before disappearing and see 开发者_运维知识库the following in the debugger regardless of what I have written in the .cpp file.

'c++ lessons.exe': Loaded 'C:\Users\User\Documents\Visual Studio 2010\Projects\c++ lessons\Debug\c++ lessons.exe', Symbols loaded.
'c++ lessons.exe': Loaded 'C:\Windows\SysWOW64\ntdll.dll', Cannot find or open the PDB file
'c++ lessons.exe': Loaded 'C:\Windows\SysWOW64\kernel32.dll', Cannot find or open the PDB file
'c++ lessons.exe': Loaded 'C:\Windows\SysWOW64\KernelBase.dll', Cannot find or open the PDB file
'c++ lessons.exe': Loaded 'C:\Windows\SysWOW64\msvcp100d.dll', Symbols loaded.
'c++ lessons.exe': Loaded 'C:\Windows\SysWOW64\msvcr100d.dll', Symbols loaded.
The program '[5904] c++ lessons.exe: Native' has exited with code 0 (0x0).

I've done a bit of searching to try and find a solution for myself. However, most of the suggestions involve hacks like adding in pauses or waiting for inputs, and I've tried Ctrl + F5. Is there a way that I can set up the build & run process in Visual Studio to display the command prompt?

---

Set a breakpoint at main()'s closing brace.

---

Go to Project->Properties->Configuration Properties->Debugging

In the command field, type: "cmd.exe"

In the Command Arguments field, type: "\k $(TargetPath)"

---

You can add commands to the Tools menu, and have their output redirected to a tab on the output window. You can use the project-specific macros as part of the command, so maybe with some fiddling about you could create a tool that runs your program (cmd /c "$(OutputPath)" might do it, I think? -- I don't have VS handy) and prints its output to the output window. This doesn't let you run it under the debugger, though.

The best solution I've found is just to suck it up. Fighting Visual Studio is wasted effort, because Visual Studio always wins. But you can make life easier on yourself. Add the following function:

void pause() {
    if(IsDebuggerPresent()) {
        printf("press enter.\n");
        getchar();
    }
}

Then register this on startup as an atexit function (since you'll want it to be called if something calls exit rather than returning from main):

atexit(&pause);

Then, the first time you run your program, and it's waiting at the "press enter" prompt, go to the console's properties and set 9,999 lines of scroll back. (I also recommend Quick Edit mode, and a smaller font, but it's up to you.) Then when you click "Apply", select "Save these options for future console windows with the same title".

This way, on subsequent runs you'll have a nice large scroll buffer, reasonably straightforward copy'n'paste, and on the offchance your program runs to a successful completion, the command prompt won't disappear immediately.

Yes, I know this is the pause solution that you don't want! -- but I've never found anything better, and, as far as it goes, it works OK.

Another approach, which you can use in conjunction with the above, is to have something like the following function, and use it instead of printf wherever possible:

void xprintf(const char *fmt, ...) {
    char buf[16384];//16K - tweak to taste
    va_list v;
    va_start(v, fmt);
    if(IsDebuggerPresent()) {
        _vsnprintf(buf, sizeof buf, fmt, v);
        buf[sizeof buf - 1] = 0;//_vsnprintf is odd
        OutputDebugString(buf);
        fputs(stdout, buf);
    } else {
        vprintf(fmt,v);
    }
    va_end(v);
 }

Now anything your program prints will go to the output window, and (until you get tired of the output window's legendary sloth, and remove the OutputDebugString call, or call xprintf more selectively...) you will be able to see your program's output even after its run has ended.

(Personally, I use all of this together. I don't understand why VS's output window is so slow, and I don't understand why it doesn't capture stdout/stderr, but since I've settled on using the above, I've found it less bothersome. The result isn't exactly great, but it's tolerable enough that you can get used to it.)