In java we can use System.out.println
In C# we can use Debug.Println
but how to do it in C++?
(The syntax, and where to look for the debug message)

Try this:

#include<windows.h>
#include<iostream>

#define DebugMessage(str)	OutputDebugString(str)

int main() {
	DebugMessage("Hello");
	std::cin.ignore();
	return 0;
}

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.

I never used OutputDebugString(). It appears to be sort of like assert(), where you can add debugging comments which don't show up when the program is compiled for release mode.

It appears to be sort of like assert(), where you can add debugging comments which don't show up when the program is compiled for release mode.

OutputDebugString works the same regardless of release/debug build.

Then why use it since you have to delete them all before releasing the program ?

Some wrapping around it is obviously needed, as for example MFC's TRACE macros.

Oh I see -- that function is meant for MFC.

No, it's rather a generic function for sending a string to a debugger.

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.

This article has been dead for over six months. Start a new discussion instead.