Empty statement

[Maksim Sipos]

Hello,
I would like to have something like

#ifdef VERSION_DEBUG
#define DEBUG(x) DebugFnc(x)
#end

#ifdef VERSION_RELEASE
#define DEBUG(x) <empty-statement>
#end

but I'm not sure how to implement the empty statement.. the problem, of
course is in the extra semicolon when the macro is called as in,
DEBUG(x); in release version. One of the possible solutions is to set

#define DEBUG(x) do{}while(0)

but I am not sure whether the compiler is smart enough
to optimize this. Any other ideas, comments?

--
Maksim Sipos

[gabriel]

What about:

#define DEBUG(x) ;

Does this work?

--
gabriel

[Kenneth Brody]

Maksim Sipos wrote:

Hello,
I would like to have something like

#ifdef VERSION_DEBUG
#define DEBUG(x) DebugFnc(x)
#end

#ifdef VERSION_RELEASE
#define DEBUG(x) <empty-statement>
#end

but I'm not sure how to implement the empty statement.. the problem, of
course is in the extra semicolon when the macro is called as in,
DEBUG(x); in release version.

[...]

Simply define it as nothing:

#define DEBUG(x)

Why is "the extra semicolon" a problem in the release version?

Can you give a sample of code where it doesn't work?

--

+---------+----------------------------------+-----------------------------+
| Kenneth | kenbrody at spamcop.net | "The opinions expressed |
| J. | http://www.hvcomputer.com | herein are not necessarily |
| Brody | http://www.fptech.com | those of fP Technologies." |
+---------+----------------------------------+-----------------------------+

[David Rubin]

Maksim Sipos wrote:

Hello,
I would like to have something like

#ifdef VERSION_DEBUG
#define DEBUG(x) DebugFnc(x)
#end

#ifdef VERSION_RELEASE
#define DEBUG(x) <empty-statement>
#end
All that is required is

#define DEBUG(x) /* nothing here */
but I'm not sure how to implement the empty statement.. the problem, of
course is in the extra semicolon when the macro is called as in,
DEBUG(x); in release version.
The semicolon will not cause any problems since it is itself a valid "empty"
statement. For example

int foo(void)
{
int i; ; ; ;;;;
;
;;;;
for(i=0; i<10; ++i);
if(i > 10){
;
}
return i;
}

is perfectly legal. Now, imagine that each semicolon above which does not
terminate a statement is proceeded by DEBUG(whatever) .
One of the possible solutions is to set

#define DEBUG(x) do{}while(0)

but I am not sure whether the compiler is smart enough
to optimize this. Any other ideas, comments?

This statement should not be optimized away since the intent is to execute the
do-while *at least* once. This is actually a very good way to implement
debugging macros since it protects against the dangling else problem as well as
introduces a scope for debugging-specific variables. For example,

if(pred)
DEBUG(stuff);
else
return 0;

If you've defined

#define DEBUG(x) if(dbgEnabled) fprintf(stderr, "DBG: x=%d\n", x)

you'll run into problems.

/david

--
Andre, a simple peasant, had only one thing on his mind as he crept
along the East wall: 'Andre, creep... Andre, creep... Andre, creep.'
-- unknown

[Maksim Sipos]

You, as well as Kenneth Brody and Gabriel are absolutely right.
For some reason I thought it was impossible to have hanging
semicolons. The next question is, assume I have the following code:

if (i == 0) DEBUG(1) ;

In the release version (DEBUG is an empty statement), will the
compiler create the "if i equals 0 then do nothing" or will it optimize
it out?
Thank you,
Maksim Sipos

"David Rubin" <no****@nowhere .net> wrote in message
news:c1******** @netnews.proxy. lucent.com...

Maksim Sipos wrote:

Hello,
I would like to have something like

#ifdef VERSION_DEBUG
#define DEBUG(x) DebugFnc(x)
#end

#ifdef VERSION_RELEASE
#define DEBUG(x) <empty-statement>
#end
All that is required is

#define DEBUG(x) /* nothing here */

but I'm not sure how to implement the empty statement.. the problem, of
course is in the extra semicolon when the macro is called as in,
DEBUG(x); in release version.

The semicolon will not cause any problems since it is itself a valid

"empty" statement. For example

int foo(void)
{
int i; ; ; ;;;;
;
;;;;
for(i=0; i<10; ++i);
if(i > 10){
;
}
return i;
}

is perfectly legal. Now, imagine that each semicolon above which does not
terminate a statement is proceeded by DEBUG(whatever) .

One of the possible solutions is to set

#define DEBUG(x) do{}while(0)

but I am not sure whether the compiler is smart enough
to optimize this. Any other ideas, comments?
This statement should not be optimized away since the intent is to execute

the do-while *at least* once. This is actually a very good way to implement
debugging macros since it protects against the dangling else problem as well as introduces a scope for debugging-specific variables. For example,

if(pred)
DEBUG(stuff);
else
return 0;

If you've defined

#define DEBUG(x) if(dbgEnabled) fprintf(stderr, "DBG: x=%d\n", x)

you'll run into problems.

/david

--
Andre, a simple peasant, had only one thing on his mind as he crept
along the East wall: 'Andre, creep... Andre, creep... Andre, creep.'
-- unknown

[Eric Sosman]

Maksim Sipos wrote: [top-posted; he'll learn better, we hope]

You, as well as Kenneth Brody and Gabriel are absolutely right.
For some reason I thought it was impossible to have hanging
semicolons. The next question is, assume I have the following code:

if (i == 0) DEBUG(1) ;

In the release version (DEBUG is an empty statement), will the
compiler create the "if i equals 0 then do nothing" or will it optimize
it out?

"Yes."

That is, it's up to the compiler, and a conforming
program can't tell whether the test was performed or not.

There are some situations where the test must *not*
be removed by optimization. Here are a few:

if (i == 0) ;
else puts ("Eeek!");
#define i putchar('\n')
if (i == 0) ;
volatile int i;
...
if (i == 0) ;

--
Er*********@sun .com

[xarax]

"Maksim Sipos" <ma*@sipos-software.com> wrote in message
news:2B******** ***********@twi ster.nyroc.rr.c om...

You, as well as Kenneth Brody and Gabriel are absolutely right.
For some reason I thought it was impossible to have hanging
semicolons. The next question is, assume I have the following code:

if (i == 0) DEBUG(1) ;

In the release version (DEBUG is an empty statement), will the
compiler create the "if i equals 0 then do nothing" or will it optimize
it out?
Thank you,
Maksim Sipos

/snip/

Well, optimizations are off-topic here, but you can probably
assume that a reasonably smart compiler will generate very
few, if any, instructions for "if (i == 0) ;".

--
----------------------------
Jeffrey D. Smith
Farsight Systems Corporation
24 BURLINGTON DRIVE
LONGMONT, CO 80501-6906
http://www.farsight-systems.com
z/Debug debugs your Systems/C programs running on IBM z/OS!
Are ISV upgrade fees too high? Check our custom product development!

[Alan Balmer]

On Fri, 20 Feb 2004 17:37:02 GMT, "Maksim Sipos"
<ma*@sipos-software.com> wrote:

if (i == 0) DEBUG(1) ;

In the release version (DEBUG is an empty statement), will the
compiler create the "if i equals 0 then do nothing" or will it optimize
it out?

Ask the compiler ;-) Or ask on a newsgroup specific to the
implementation you're using. Unlike your first question, this one is
off-topic, since the C standard has nothing to say on the subject.

--
Al Balmer
Balmer Consulting
re************* ***********@att .net

[Peter Pichler]

"gabriel" <[e-mail]> wrote in message
news:d2******** *************** ***@msgid.megan ewsservers.com. ..

What about:

#define DEBUG(x) ;
[ In the following context:

#ifdef VERSION_DEBUG
#define DEBUG(x) DebugFnc(x)
#end

#ifdef VERSION_RELEASE
#define DEBUG(x) <empty-statement>
#end
]
Does this work?

Of course not. Try:

if (something_or_o ther)
DEBUG(x);
else
DEBUG(y);

Your solution translates to two semicolons, which in this case is a syntax
error.

To the OP: try something like:

#define DEBUG(x) ((void)0)

Neat, portable, syntactically safe and (generally) does not eat CPU cycles.

Peter

[Guillaume]

> if (i == 0) DEBUG(1) ;

In the release version (DEBUG is an empty statement), will the
compiler create the "if i equals 0 then do nothing" or will it optimize
it out?

The question is: will it perform whatever is in the 'if' condition or
not?

If the compiler is half-decent, it will of course generate no code for
this, provided that the condition doesn't have any side effect. If it
does, the compiler *has* to generate the condition inside the 'if', but
it will not generate any "flow control" code (since there is no two
different paths).

In your example, if 'i' is a variable, the whole 'if' statement will
lead to no code at all. Now, if 'i' is actually a macro that could have
side effects, the compiler has to generate the code for this macro.

For instance:

if (printf("Hello. \n")) ;

The 'printf' call can't be "optimized out".