3

I'm working on a windows application in C++, and I'd like to use cout for debugging purposes.
It seems that the effects of cout are hidden, is there a configuration option that will allow a console window to open with my debug information?

TechplexEngineer
  • 1,836
  • 2
  • 30
  • 48
  • 2
    dup of http://stackoverflow.com/questions/1333527/how-do-i-print-to-the-debug-output-window-in-a-win32-app – Sergei Nikulov Jun 18 '12 at 14:34
  • 2
    @Sergey: No, that's not a dupe. That's asking about writing with `OutputDebugString`. That doesn't/won't make `cout` usable (though it is, IMO, a perfectly valid *alternative*). – Jerry Coffin Jun 18 '12 at 15:00

6 Answers6

2

You have a couple of reasonable options. One is to rename your entrypoint from WinMain to main, so it'll be built as a console application. That can still use things like RegisterClass and CreateWindow just fine.

The obvious alternative would be to use OutputDebugString instead of cout. The output from that will show up in a debugger, or any number of programs built specifically to display what it produces (basically mini-debuggers that just don't provide other debugging capabilities).

A third solution I'd consider less reasonable is to call AllocConsole to allocate a console, then write to it. If you don't mind doing all your writing with Windows-native console functions (WriteFile, WriteConsoleOutput, etc.) that's fine. Unfortunately, it won't initialize the C++ streams to work with the console, so you'll need to either open file streams pointing the console, or else find and use the (undocumented) function that initializes the streams library for the console. While this can be made to work, you end up doing extra work to write non-portable code, and little (if any) advantage to make up for it (and in this case, "non-portable" can include not even working with other versions of the same compiler, at least if you invoke the library's initialization function).

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
  • Redirecting `cout` is quite portable. I think you'd end up with a grand total of two lines of Windows-specific code -- the one calling `AllocConsole`, and the one containing the special filename `"CONOUT$"`. I wouldn't consider `OutputDebugString` a viable alternative at all, since it doesn't support any formatting, let alone compatibility with functions designed for `iostreams`. – Ben Voigt Jun 18 '12 at 14:42
  • @BenVoigt: A front end that formats with `vsprintf`, then uses `OutputDebugString` is trivial. A streabuf whose `overflow` uses `OutputDebugstring` isn't *quite* as trivial, but still not exactly rocket science. – Jerry Coffin Jun 18 '12 at 14:58
  • Using `vsprintf` is only trivial if you don't care about possible buffer overflow. – Ben Voigt Jun 18 '12 at 15:24
  • @BenVoigt: How often is that a problem for debugging output? At least in my experience with it (admittedly limited -- only 3 decades or so) the answer to that is "never." – Jerry Coffin Jun 18 '12 at 15:35
  • Depends on what you're debugging, I suppose. If you had a problem where an input string wasn't correctly NUL-terminated, or a file used the wrong line ending and therefore was treated as one massive line instead of many short ones, I can easily imagine where data sent to the debug output could be much much larger than designed. After all, debug information is most useful when inputs differ from expectations. – Ben Voigt Jun 18 '12 at 15:40
  • Thanks for the information. Your answers and comments led me to find this library which handles allocConsole for me. http://www.halcyon.com/~ast/dload/guicon.htm Thanks Guys! – TechplexEngineer Jun 19 '12 at 13:39
2

To add a console window to a GUI application, you can use the AllocConsole API.

Then you just need to open the special file name "CONOUT$" and attach your streams to it (cout, cerr, etc)

See this explanation on MSDN.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
1

I believe the accepted answers are actually not what you are looking for. You say you need it only for debugging, not for release. Your best options are:

a) redirect stdout and stderr to a file and then inspect the file. This you can set in the VS project Properties > Configuration Properties > Debugging > Command Arguments: you should enter >out.txt 2>&1. This will output both stdout and stderr to out.txt

b) set your debug (you say you need it only for debugging) configuration Properties > Configuration Properties > Linker > System > SubSystem to Console (/SUBSYSTEM:CONSOLE). Then you can run the project with F5, but it will hide the console window when your application finishes. If you run it with Ctrl+F5 (but then you will not have debugger attached), then it will not be hidden.

0

The simplest way to do this is to start a Console application from scratch:

In VisualStudio, File > New Project. Select Win32 Console Application. Select various options and create the new project.

Note that although it says Win32 Console Application, you can create x64 builds without restriction.

At this point you have an application shell. If you already have code and you want to bring it in to this new project, simply do Project > Add Existing Item... and select the files to include in the project.

John Dibling
  • 99,718
  • 31
  • 186
  • 324
0

Managing a console from a GUI program is horribly messy, and I suggest you do it another way. For instance, if you need to see the messages in real time, display them in a window; if not, write them to a file.

TonyK
  • 16,761
  • 4
  • 37
  • 72
0

just use OutputDebugString() but remember to either set your character set to multibyte, or if you don't want to do that, you could write your code like this:

// with multibyte character set:

   OutputDebugString("Failed to do something");

// without multibyte character set:

   OutputDebugString(L"Failed to do something");