You are using a compiler with the world's best debugger. You don't need debug messages. Just compile your program for debug and use the debugger to set breakpoints, see the value of variables and program execution.

But to answer your question, how to print debug messages depends on whether you are writing a console program or a windows program. Console progrm: just using normal print() or cout statements wherever you want them. Windows programs are more difficult because it doesn't have a console window, so you have to use win32 api text output functions

I agree with AD on that, but there has been times when its been helpfull to use OutputDebugString to print directly to the output window, for example when I was working on a scheduler, every few minutes it would have display its status, which isn't possible to do using breakpoints. I suppose I could have also made a log file to do that but I found this way easier.

You are using a compiler with the world's best debugger. You don't need debug messages. Just compile your program for debug and use the debugger to set breakpoints, see the value of variables and program execution.

This isn’t entirely true. While the debugger is great for most apps, there are times when it is not feasible, if not outright impossible to use the debugger.

It’s called Heisenberg debugging, Heisenbugging, debugging Heisenbugs, etc. after the Heisenberg Uncertainty Principal. There are situations where the act of debugging itself affects the behavior being debugged. In those situations, the debugger (breakpoints) don’t work—neither does MessageBox usually—and so printing to the debug console (or other log) is necessary.

For example, multi-threaded apps often don’t lend themselves well to the debugger (which is going to be a problem since software dev is moving more and more towards multi-threading since the recent proliferation of multi-cores and multi-threads APIs). Also, debugging things like ShowWindow behavior would be a huge pain in the butt if not impossible with the debugger since every time the program breaks, the app gets WM_SHOWWINDOW messages to hide/show. Sometimes, debugging things like drivers or kernel mode functions are difficult with the debugger. Sometimes even when it’s possible to use the debugger, it’s just faster and easier to let the program run and then analyze the debug output, especially for big loops and such which would require setting conditions and such if using breakpoints.