It's bad, because the two versions behave differently.

When you use the DEBUG version, DebugCode( code_fragment ) becomes { code_fragment }

This variable, pointer, function, whatever it is, still exists.

But on the undefined DEBUG version, all references to DebugCode ( code_fragment ) should be replaced with a value of 1! (It is defined, but has no other value.)
--------------------------------
Also, if you meant to put the space after the DebugCode, then DebugCode will become ( code_fragment ). Not the same either!

I'm not sure if that was intentional, so I answered it both ways.

Also, the non-DEBUG version of the macro should have SOMETHING in its definition. That too is thin ice in terms of compiler/linker implementation.

- Splat

#define DebugCode ( code_fragment )

this line is invalid. for macros to accept arguments you have to put the opening parenthesis right after the label WITHOUT A SPACE.

Doing this makes code look very untidy lets see

Debugcode(
{
...
}
)

Now I don't know if it's just me but code within a call be it macro, method, procedure or funtion call is ugly!
The idea is with macros is to repreat simple procedures that are better in-lined with the rest of the code and I generally find that using the key word "inline" in your procedure decleration does exactly the same thing but makes it a lot easyer to debug!

eg.

int inline macrocode()
{
...
}

also no need to put a '/' at the end of each line.

Plus if you use a code editor that hilights key words such as #define
then just put around you code blocks

#ifdef DEBUG
//code segment
#endif

you will be able to easily see the code blocks.

Thouse who use Microsofts Visuel C++ will find that if you compile a debug version the definition is automatically declered so you don't have to add the define or remove it when you are compiling debug or release versions.

as Moth already suggested.

What I didn't see above was a definitive answer....what exactly does the compiler do with Dan's statement?