I have had the pleasure of writing a pretty large number of apps for Windows. There are a few things that I have learned, over time, that have really helped to improve my productivity. One of those things is a basic debug console.
Typically, a debug console is handy – go figure – while you’re debugging. Once you have a release quality build, you won’t want the debug console hanging around anymore.
This is one of those snippets of code that, while brutally simple, is rather non-obvious and most people don’t know of.
#ifdef MYAPP_DEBUG_TRACE if(AllocConsole()) { freopen("CONOUT$", "wt", stdout); SetConsoleTitle(L"MyApp : Debug Console"); SetConsoleTextAttribute(GetStdHandle(STD_OUTPUT_HANDLE), FOREGROUND_GREEN | FOREGROUND_BLUE | FOREGROUND_RED); printf("n"); printf(" MyApp Debug Consolen"); printf("n"); } #endif
Basically this code, if debug trace preprocessor is set (add MYAPP_DEBUG_TRACE to your preprocessor settings), will allocate a nice little debug console window, change the title, set the font colors, and redirect standard output to the console.
This snippet of code can be added to any Win32 application, and gives you the instant capability to spit out oodles of delicious debugging data. Typically, I combine this method with something along these lines:
#ifdef __cplusplus inline void null_func(char *format, ...) { } #define DbgEmpty null_func #else #define DbgEmpty { } #endif
/* Debug Trace Enabled */ #ifdef MYAPP_DEBUG_TRACE #include #define DbgPrintf printf #else /* Debug Trace Disabled */ #define DbgPrintf DbgEmpty #endif
Now, you can use the function “DbgPrintf” just as if it was “printf” – and it will compile away to nothing in a release mode build!
Hi there!
I like your work a lot, especially the neato idea you did with CxBx. This is also very useful to me, as I have one such debug console permanently in my application, and when releasing I turn it off in the DevCpp’s options. This is a much cleaner solution (but why am I telling you this when you know it?)
Well, nuff nonsense talk, I just wanted you to know that I appreciate it a lot π
LikeLike
Why not just OutputDebugString() and catch with SysInternals’ DebugView (or similar)?
LikeLike
I can think of at least three problems with OutputDebugString:
1) In release mode, the debugging strings will still exist in the binary.
2) In release mode, the code (and associated overhead) will still exist in the binary.
3) It is necessary to run an additional, separate, tool – e.g. DebugView.
You can also expand this method easily to pipe to a file, for example.
If you prefer OutputDebugString, anyway, you could at still use DbgPrintf, but when creating the #define, wrap OutputDebugString instead of printf. This will prevent 2 of the issues I listed.
LikeLike
I actually prefer having it in a separate process. It also provides more features, like a large scrollable buffer, GUI, and more. And of course, conditional #defines work for that too. I wouldn’t leave debug info in a final build! π
LikeLike
I’m not a programmer i’m a poor neuroscientist but i’d just like to say that i read your blog and i really like it it makes me smile a lot!
LikeLike
You should try to make a tema work with the Xeon staff.
LikeLike
I just happened to find your tip when I was searching for the reason why my application was not outputting printfs (turns out it’s a Win32 app and not a console, so there was no “output”, so to speak).
Your tip has been very helfpul – thanks!
LikeLike
GREAT! just what I was looking for!
LikeLike
Thanks sir caustik. I’m using this in my emulator π
LikeLike
hi caustik, I’ve just stumbled across your website, and this article. Its just what I’m looking for!
Although – I think I may be missing something. I pasted your code snippet it into my Win32 app. I’m generating the console OK, and the title sets fine, but the printf’s do not produce any output.
My app is written in C++, so I tried
std::cout << “blah”; but that doesn’t produce output either… am I missing something?
thanks
B
LikeLike
That is strange. What compiler and OS is this on? Are you using cygwin? (I have only tested this one MSVC)
LikeLike
I just found this explanation on http://www.codeproject.com
“It is important that you create your console before you create the main window. If you don’t, the console will still be created, but your debugging messages send with _cprintf() will not arrive in your console. I couldn’t figure out why it is like this, only that it is like this.”
This fits, I’m not creating the console until after my main window has been created.
LikeLike
Just saw your comment – its Windows XP and using MS Visual Studio 2005 – Express Edition.
LikeLike
Actually, no matter where in my application I put the code snippet, I still don’t get any debug output. I think my original post about creating the console before creating the main window was wrong perhaps.
LikeLike
This is great! Thanks.
LikeLike
After reading this article, I feel that I need more info. Can you suggest some more resources ?
LikeLike
One of the most useful snippets I’ve ever found. Thank you π
LikeLike
Hi
great snippet, worked immediately!!
On some pages they tell you on ten pages how to redirect the printf command.
For people who have no time for nerdy talking… this worked in 10 seconds.
Thanks a lot!!
LikeLike