In many C/C++ macros I'm seeing the code of the macro wrapped in what seems like a meaningless do while loop. Here are examples.
#define FOO(X) do { f(X); g(X); } while (0)
#define FOO(X) if (1) { f(X); g(X); } else
I can't see what the do while is doing. Why not just write this without it?
#define FOO(X) f(X); g(X)
The do ... while and if ... else are there to make it so that a
semicolon after your macro always means the same thing. Let's say you
had something like your second macro.
#define BAR(X) f(x); g(x)
Now if you were to use BAR(X); in an if ... else statement, where the bodies of the if statement were not wrapped in curly brackets, you'd get a bad surprise.
if (corge)
BAR(corge);
else
gralt();
The above code would expand into
if (corge)
f(corge); g(corge);
else
gralt();
which is syntactically incorrect, as the else is no longer associated with the if. It doesn't help to wrap things in curly braces within the macro, because a semicolon after the braces is syntactically incorrect.
if (corge)
{f(corge); g(corge);};
else
gralt();
There are two ways of fixing the problem. The first is to use a comma to sequence statements within the macro without robbing it of its ability to act like an expression.
#define BAR(X) f(X), g(X)
The above version of bar BAR expands the above code into what follows, which is syntactically correct.
if (corge)
f(corge), g(corge);
else
gralt();
This doesn't work if instead of f(X) you have a more complicated body of code that needs to go in its own block, say for example to declare local variables. In the most general case the solution is to use something like do ... while to cause the macro to be a single statement that takes a semicolon without confusion.
#define BAR(X) do { \
int i = f(X); \
if (i > 4) g(i); \
} while (0)
You don't have to use do ... while, you could cook up something with if ... else as well, although when if ... else expands inside of an if ... else it leads to a "dangling else", which could make an existing dangling else problem even harder to find, as in the following code.
if (corge)
if (1) { f(corge); g(corge); } else;
else
gralt();
The point is to use up the semicolon in contexts where a dangling semicolon is erroneous. Of course, it could (and probably should) be argued at this point that it would be better to declare BAR as an actual function, not a macro.
In summary, the do ... while is there to work around the shortcomings of the C preprocessor. When those C style guides tell you to lay off the C preprocessor, this is the kind of thing they're worried about.
Macros are copy/pasted pieces of text the pre-processor will put in the genuine code; the macro's author hopes the replacement will produce valid code.
There are three good "tips" to succeed in that:
Help the macro behave like genuine code
Normal code is usually ended by a semi-colon. Should the user view code not needing one...
doSomething(1) ;
DO_SOMETHING_ELSE(2) // <== Hey? What's this?
doSomethingElseAgain(3) ;
This means the user expects the compiler to produce an error if the semi-colon is absent.
But the real real good reason is that at some time, the macro's author will perhaps need to replace the macro with a genuine function (perhaps inlined). So the macro should really behave like one.
So we should have a macro needing semi-colon.
Produce a valid code
As shown in jfm3's answer, sometimes the macro contains more than one instruction. And if the macro is used inside a if statement, this will be problematic:
if(bIsOk)
MY_MACRO(42) ;
This macro could be expanded as:
#define MY_MACRO(x) f(x) ; g(x)
if(bIsOk)
f(42) ; g(42) ; // was MY_MACRO(42) ;
The g function will be executed regardless of the value of bIsOk.
This means that we must have to add a scope to the macro:
#define MY_MACRO(x) { f(x) ; g(x) ; }
if(bIsOk)
{ f(42) ; g(42) ; } ; // was MY_MACRO(42) ;
Produce a valid code 2
If the macro is something like:
#define MY_MACRO(x) int i = x + 1 ; f(i) ;
We could have another problem in the following code:
void doSomething()
{
int i = 25 ;
MY_MACRO(32) ;
}
Because it would expand as:
void doSomething()
{
int i = 25 ;
int i = 32 + 1 ; f(i) ; ; // was MY_MACRO(32) ;
}
This code won't compile, of course. So, again, the solution is using a scope:
#define MY_MACRO(x) { int i = x + 1 ; f(i) ; }
void doSomething()
{
int i = 25 ;
{ int i = 32 + 1 ; f(i) ; } ; // was MY_MACRO(32) ;
}
The code behaves correctly again.
Combining semi-colon + scope effects?
There is one C/C++ idiom that produces this effect: The do/while loop:
do
{
// code
}
while(false) ;
The do/while can create a scope, thus encapsulating the macro's code, and needs a semi-colon in the end, thus expanding into code needing one.
The bonus?
The C++ compiler will optimize away the do/while loop, as the fact its post-condition is false is known at compile time. This means that a macro like:
#define MY_MACRO(x) \
do \
{ \
const int i = x + 1 ; \
f(i) ; g(i) ; \
} \
while(false)
void doSomething(bool bIsOk)
{
int i = 25 ;
if(bIsOk)
MY_MACRO(42) ;
// Etc.
}
will expand correctly as
void doSomething(bool bIsOk)
{
int i = 25 ;
if(bIsOk)
do
{
const int i = 42 + 1 ; // was MY_MACRO(42) ;
f(i) ; g(i) ;
}
while(false) ;
// Etc.
}
and is then compiled and optimized away as
void doSomething(bool bIsOk)
{
int i = 25 ;
if(bIsOk)
{
f(43) ; g(43) ;
}
// Etc.
}
#jfm3 - You have a nice answer to the question. You might also want to add that the macro idiom also prevents the possibly more dangerous (because there's no error) unintended behavior with simple 'if' statements:
#define FOO(x) f(x); g(x)
if (test) FOO( baz);
expands to:
if (test) f(baz); g(baz);
which is syntactically correct so there's no compiler error, but has the probably unintended consequence that g() will always be called.
The above answers explain the meaning of these constructs, but there is a significant difference between the two that was not mentioned. In fact, there is a reason to prefer the do ... while to the if ... else construct.
The problem of the if ... else construct is that it does not force you to put the semicolon. Like in this code:
FOO(1)
printf("abc");
Although we left out the semicolon (by mistake), the code will expand to
if (1) { f(X); g(X); } else
printf("abc");
and will silently compile (although some compilers may issue a warning for unreachable code). But the printf statement will never be executed.
do ... while construct does not have such problem, since the only valid token after the while(0) is a semicolon.
Explanation
do {} while (0) and if (1) {} else are to make sure that the macro is expanded to only 1 instruction. Otherwise:
if (something)
FOO(X);
would expand to:
if (something)
f(X); g(X);
And g(X) would be executed outside the if control statement. This is avoided when using do {} while (0) and if (1) {} else.
Better alternative
With a GNU statement expression (not a part of standard C), you have a better way than do {} while (0) and if (1) {} else to solve this, by simply using ({}):
#define FOO(X) ({f(X); g(X);})
And this syntax is compatible with return values (note that do {} while (0) isn't), as in:
return FOO("X");
While it is expected that compilers optimize away the do { ... } while(false); loops, there is another solution which would not require that construct. The solution is to use the comma operator:
#define FOO(X) (f(X),g(X))
or even more exotically:
#define FOO(X) g((f(X),(X)))
While this will work well with separate instructions, it will not work with cases where variables are constructed and used as part of the #define :
#define FOO(X) (int s=5,f((X)+s),g((X)+s))
With this one would be forced to use the do/while construct.
Jens Gustedt's P99 preprocessor library (yes, the fact that such a thing exists blew my mind too!) improves on the if(1) { ... } else construct in a small but significant way by defining the following:
#define P99_NOP ((void)0)
#define P99_PREFER(...) if (1) { __VA_ARGS__ } else
#define P99_BLOCK(...) P99_PREFER(__VA_ARGS__) P99_NOP
The rationale for this is that, unlike the do { ... } while(0) construct, break and continue still work inside the given block, but the ((void)0) creates a syntax error if the semicolon is omitted after the macro call, which would otherwise skip the next block. (There isn't actually a "dangling else" problem here, since the else binds to the nearest if, which is the one in the macro.)
If you are interested in the sorts of things that can be done more-or-less safely with the C preprocessor, check out that library.
For some reasons I can't comment on the first answer...
Some of you showed macros with local variables, but nobody mentioned that you can't just use any name in a macro! It will bite the user some day! Why? Because the input arguments are substituted into your macro template. And in your macro examples you've use the probably most commonly used variabled name i.
For example when the following macro
#define FOO(X) do { int i; for (i = 0; i < (X); ++i) do_something(i); } while (0)
is used in the following function
void some_func(void) {
int i;
for (i = 0; i < 10; ++i)
FOO(i);
}
the macro will not use the intended variable i, that is declared at the beginning of some_func, but the local variable, that is declared in the do ... while loop of the macro.
Thus, never use common variable names in a macro!
I don't think it was mentioned so consider this
while(i<100)
FOO(i++);
would be translated into
while(i<100)
do { f(i++); g(i++); } while (0)
notice how i++ is evaluated twice by the macro. This can lead to some interesting errors.
Related
A topic has the following code, which is required to indicate the location of the error.
#include<iostream>
#define PT 3.5;
#define S(x) PT*x*x
void main() {
int a = 1, b = 2;
std::cout << S(a + b);
}
I think ";" caused this problem ,and deleted ';' the post compilation test can get the correct results.But the teacher thinks that variables cannot be used in macro definition.
I'm not sure who is right.
I've seen a lot of answers, but what I want to know is not whether it's reasonable to write like this, but what causes the program error in the end.
Add ';' after '#define' Not particularly good, but the compilation can pass. "#define" can also allow variables to appear. So the final error reason is "* a + b"?
There's a couple of problems. Yes, the PT will expand to 3.5; and cause a syntax error. Change that to:
#define PT 3.5
The other issue is that S(a + b) will expand to PT*a + b*a + b which is clearly not what you want. As a matter of convention, macros that perform arithmetic should wrap any expandable parts in parentheses, and the entire macro should also be in parentheses:
#define S(x) ((PT)*(x)*(x))
This ensures that you don't have to worry about expanded expressions wreaking havoc due to operator precedence rules.
Regarding the comment about your teacher...
the teacher thinks that variables cannot be used in macro definition
It's possible that they are talking about the fact that x is just a placeholder for expansion. If you pass a + b and use x twice, then a + b will be evaluated twice. Imagine if you called S(++a)... You'd get PT*(++a)*(++a)
It's usually more appropriate to just write a function, and that avoids problems like the above.
double S(int x) {
return PT * x * x;
}
Or even:
template<class T>
double S(T x) {
return PT * x * x;
}
Macros are just text substitution, so you can do pretty much anything you want, as long as the result of the substitution is valid code. So the literal answer to "Can ';' be added after #define" is yes, but the result might not work.
#define calc(x) ((x) * (x));
void f() {
int g = 3;
int h = calc(g);
}
The result of the macro expansion is
int h = ((g) * (g));;
That's valid code; the second semicolon marks the end of an empty expression, just as if it had been written
int h = ((g) * (g));
;
That's bad style, of course, and it could cause problems in other contexts, so the "right" way to use that macro would be
int h = calc(g)
That way, the text that results from the macro expansion would only have one semi-colon. But that looks weird, and the macro really shouldn't have that semicolon in it.
As to using variables, again, it depends on what the result of the text substitution is.
#define calc (x) * (x)
void f() {
int x = 3;
int y = calc;
}
That's okay; the code is equivalent to
void f() {
int x = 3;
int y = (x) * (x);
}
On the other hand, this isn't okay:
void f() {
int b = 3;
int y = calc;
}
It doesn't work because there is no x there. So this macro has vary limited usefulness; there are rare situations where it might be appropriate, but, in general, it's a bad idea.
You can't put a semicolon after PT because your macro S(X) PT*x*x would get processed to 3.5;*x*x
Your S(x) macro is breaking because the semicolons breaks it into 2 statements. First is 3.5; and the second one is *x*x
hence why you get the error.
To make it work you simply need to remove the ; in your definition of PT
I want to create a macro that replaces all calls to printf, more specifically mbedtls_printf (which behaves the exact sameway as printf) with nothing.
I know I can use #define mbedtls_printf to replace mbedtls_printf with nothing, but this will still leave the parameters/parenthesis intact.
Edit - I forgot to mention that mbedtls_printf is a macro that replaces itself with sgx_printf
I would go with:
#define printf(...) (0)
The benefit here is that it will continue to compile in cases where someone actually bothers to check the return from printf (rare but not unheard of).
The following works, at least with gcc 8. A brief search suggests that variadic macros were introduced with C99:
#define printf(...) do { } while (0)
int main()
{
printf("Hello %s?\n", "world");
return 0;
}
You want to use the ol' "do {} while (0)" trick, in order to avoid surprises like:
if (something)
printf("Something else");
will_this_be_invoked_or_not();
You can't make printf() disappear completely. Because this would make the next line a logical part of the preceding if statement. Hillarity ensues. That's why you still have to leave something in place.
If you completely no-op out the printf statements, there may be a bug lurking. Consider the following code:
printf("Result is %d\n", DoSomethingVeryImportant());
When you replace the printf call with a macro, you likely still want to make sure the inner function call to DoSomethingVeryImportant() is invoked. Otherwise, you've changed the logic of your program.
And I suppose you might want to have your mbedtls_printf actually call printf for debug builds, but be a no-op in a retail build.
If all of the above is of value, consider this as mbedtls_printf.h:
#ifndef MBEDTLS_PRINTF_H
#define MBEDTLS_PRINTF_H
#include <stdarg.h>
#include <stdio.h>
#ifdef DEBUG_BUILD
inline int printf_stub(const char* s, ...)
{
va_list args;
va_start(args, s);
vprintf(s, args);
va_end(args);
}
#define mbedtls_printf(...) printf_stub(__VA_ARGS__)
#else
inline int printf_stub(...){return 1;}
#define mbedtls_printf(...) printf_stub(__VA_ARGS__)
#endif
#endif
Then in code:
#include <iostream>
#include "mbedtls_printf.h"
int ImportantFunction()
{
std::cout << "Really important code" << std::endl;
return 42;
}
int main()
{
mbedtls_printf("Result of a very important step: %d\n", ImportantFunction());
mbedtls_printf("This just happened");
mbedtls_printf("Result of a another important step: ", 43, 44, ImportantFunction());
return 0;
}
The compiler will optimize out the empty function call and still invoke ImportantFunction() as it was doing originally.
I know I can use #define mbedtls_printf to replace mbedtls_printf with nothing, but this will still leave the parameters/parenthesis intact.
It's OK if the argument list remains, because then it will be treated as an expression. If we have an expression and we do nothing to it, then it will just be optimized out (on any decent compiler). Consider the following:
int x(char a, double b)
{
return printf("%c %f\n", a, b);
}
#define x
int main(void)
{
x('P', 3.14);
}
The compiler sees the following code for main:
('P', 3.14);
This expression evaluates to 3.14 (the comma operator returns its right-hand operand). Such an expression is quietly optimized.
Just use a lambda: (Variadic macros since C99)
#define printf(...) []{}()
What this does is simply replace the printf() calls to []{}()... This just means an empty function call... which can be formatted to be like this:
#define printf(...) [] { \
}()
Or, even this suffices:
// Replacing printf() with an empty function that just takes variadic arguments
#define printf [](...){}
Edit: You can also use:
#define printf void(0)
Suppose I have a macro defined as this:
#define FOO(x,y) \
do {
int a,b;
a = f(x);
b = g(x);
y = a+b;
} while (0)
When expanding the macro, does GCC "guarantee" any sort of uniqueness to a,b? I mean in the sense that if I use FOO in the following manner:
int a = 1, b = 2;
FOO(a,b);
After, preprocessing this will be:
int a = 1, b = 2;
do {
int a,b;
a = f(a);
b = g(b);
b = a+b;
} while (0)
Can/will the compiler distinguish between the a outside the do{} and the a inside the do? What tricks can I use to guarantee any sort of uniqueness (besides making the variables inside have a garbled name that makes it unlikely that someone else will use the same name)?
(Ideally functions would be more useful for this, but my particular circumstance doesn't permit that)
If we consider scoping of variables, it is guaranteed that a,b inside the do..while() will be different from the ones defined outside.
For your case, the a,b defined outside will not exist inside the do..while().
There are lots of things to watch out for when using MACROs.
Macros perform just string substitution. The semantic is low and the the compiler have a limited knowledge of the preprocessor (essentially #pragma which in fact is not a preprocessor keyword, and source line info).
In your case a and b are not initialized local value. Behavior is unpredictible.
Your expanded code is equivalent to the following one.
int a = 1, b = 2;
do {
int a___,b___;
a___ = f(a___);
b___ = g(b___);
b___ = a___+b___;
} while (0)
To avoid such case in c++ prefer the use of inline function or template.
If you use a c 1999 compliant compiler, you can use inline in c language.
http://en.wikipedia.org/wiki/Inline_function
In c you can make safer macro by defining longer variable and surrounding parameter by () :
#define FOO(x,y) \
do {
int FOO__a,FOO__b;
FOO__a = f(x);
FOO__b = g(x);
y = FOO__a+FOO__b + (y)*(y);
} while (0)
Note : I changed your example by adding a (y)*(y) to illustrate the case
It is also a good practice to use only once macro parameter.
This prevent side effects like that:
#define max(a,b) a>b?a:b
max(i++,--y)
Max will not return what you want.
Variables a and b are treated just as any local variables inside a local scope.
The C language guarantees that if those variables happen to have the same names as outer scope variables, the local variables will be the ones updated.
Here is an example to illustrate:
#include <stdio.h>
#define FOO(x) \
{ \
int a; \
a = x; \
printf("%d\n", a); \
}
int main()
{
int a = 1;
{
int a = 2;
printf("%d\n", a); // 2
FOO(3); // 3
printf("%d\n", a); // 2
}
printf("%d\n", a); // 1
getchar();
}
Now, of course it might be a bright idea to not name every single variable in your program "a" just because C guarantees that local variables take precedence. But technically there is nothing stopping you from it.
Btw MISRA-C bans naming like this, it require each variable no matter scope to have an unique name, for readability and maintenance reasons.
(As a sidenote, function-like macros is incredibly poor programming style and shouldn't be used. Use real functions instead, and inline them if performance is critical.)
There is no tricks other than garbling. The C and C++ preprocessors do not have the equivalent of lisp gensym or hygienic macros.
Nope, there is no guarantee of uniqueness.
Infact, your code is about to fail.
Macros are just like replacement of text.
I usually use crazy variable names if I am inside a macro, like this:
#define FOO(x,y) \
do {
int FOO_MACRO_a, FOO_MACRO_b;
FOO_MACRO_a = f(x);
FOO_MACRO_b = g(x);
y = FOO_MACRO_a + FOO_MACRO_b;
} while (0)
If you are targeting gcc and/or g++ then you can use their special macro block feature:
#define max(x, y) ({ typeof(x) a_ = (x); \
typeof(y) b_ = (y); \
(a_ > b_) ? a_ : b_ })
This allows you to create unique local variables, very much the same as writing a function.
Of course, for portability, it's not recommended. On the other hand, if you only plan to work on systems that offer gcc/g++, it will work on all of those.
Source: http://gcc.gnu.org/onlinedocs/gcc-3.0.1/cpp_3.html#SEC30
Further, with gcc / g++ you can use the -Wshadow command line option. In the event you inadvertently reuse a local variable with the same name, it will warn you. You can further use -Werror to transform those warnings in error. Now you can't compile if there is the possibility of a mixed up variable. You need to make sure to use a block, though. A do/while() as others have presented would do the job.
int a;
// code from macro;
do { int a = 5; ... } while(false);
With the combo I just described (-Wshadow + -Werror), you get an error when you do int a = 5.
You can actually make sure that regardless of what x and y are you won't have this problem by doing the following:
#define FOO(x,y) \
do\
{\
int x##y##a,x##y##b;\
x##y##a = f(x);\
x##y##b = g(x);\
y = x##y##a + x##y##b;\
} while (0)
By making sure a and b names contains x and y names you know they are different. But that's a really bad code and you probably shouldn't code like this.
Macros are textually expanded as is, modulo parameter replacement, so there's nothing the compiler can do to provide the sort of guarantee you're asking for -- as you can see in the expansion, the a parameter will refer to the inner a, not the outer one. The solution is indeed to use "garbled" names, e.g. int FOO_a, FOO_b;
In your macro that is indeed a danger and so is the possible reuse of x which is not guaranteed to be an l-value and could change by being used in the macro twice.
Even if you do need a macro, it can still be a light wrapper around an inline function, and one such that will take x and give you both f(x) and g(x) without possibly having to re-evaluate x would certainly be safe.
In your case something like:
template< typename T >
struct Foo
{
T& x;
explicit Foo(T&x_) : x(x_)
{
}
int f();
int g();
};
template<typename T>
Foo<T> makeFoo(T& x)
{
return Foo<T>(x);
}
#define FOO(x,y)
{
Foo FOO_VAR(x);
y = FOO_VAR.f() + FOO_VAR.g();
}
would be a safer way to do things. Of course if you don't need the macro at all, do away with it.
In many C/C++ macros I'm seeing the code of the macro wrapped in what seems like a meaningless do while loop. Here are examples.
#define FOO(X) do { f(X); g(X); } while (0)
#define FOO(X) if (1) { f(X); g(X); } else
I can't see what the do while is doing. Why not just write this without it?
#define FOO(X) f(X); g(X)
The do ... while and if ... else are there to make it so that a
semicolon after your macro always means the same thing. Let's say you
had something like your second macro.
#define BAR(X) f(x); g(x)
Now if you were to use BAR(X); in an if ... else statement, where the bodies of the if statement were not wrapped in curly brackets, you'd get a bad surprise.
if (corge)
BAR(corge);
else
gralt();
The above code would expand into
if (corge)
f(corge); g(corge);
else
gralt();
which is syntactically incorrect, as the else is no longer associated with the if. It doesn't help to wrap things in curly braces within the macro, because a semicolon after the braces is syntactically incorrect.
if (corge)
{f(corge); g(corge);};
else
gralt();
There are two ways of fixing the problem. The first is to use a comma to sequence statements within the macro without robbing it of its ability to act like an expression.
#define BAR(X) f(X), g(X)
The above version of bar BAR expands the above code into what follows, which is syntactically correct.
if (corge)
f(corge), g(corge);
else
gralt();
This doesn't work if instead of f(X) you have a more complicated body of code that needs to go in its own block, say for example to declare local variables. In the most general case the solution is to use something like do ... while to cause the macro to be a single statement that takes a semicolon without confusion.
#define BAR(X) do { \
int i = f(X); \
if (i > 4) g(i); \
} while (0)
You don't have to use do ... while, you could cook up something with if ... else as well, although when if ... else expands inside of an if ... else it leads to a "dangling else", which could make an existing dangling else problem even harder to find, as in the following code.
if (corge)
if (1) { f(corge); g(corge); } else;
else
gralt();
The point is to use up the semicolon in contexts where a dangling semicolon is erroneous. Of course, it could (and probably should) be argued at this point that it would be better to declare BAR as an actual function, not a macro.
In summary, the do ... while is there to work around the shortcomings of the C preprocessor. When those C style guides tell you to lay off the C preprocessor, this is the kind of thing they're worried about.
Macros are copy/pasted pieces of text the pre-processor will put in the genuine code; the macro's author hopes the replacement will produce valid code.
There are three good "tips" to succeed in that:
Help the macro behave like genuine code
Normal code is usually ended by a semi-colon. Should the user view code not needing one...
doSomething(1) ;
DO_SOMETHING_ELSE(2) // <== Hey? What's this?
doSomethingElseAgain(3) ;
This means the user expects the compiler to produce an error if the semi-colon is absent.
But the real real good reason is that at some time, the macro's author will perhaps need to replace the macro with a genuine function (perhaps inlined). So the macro should really behave like one.
So we should have a macro needing semi-colon.
Produce a valid code
As shown in jfm3's answer, sometimes the macro contains more than one instruction. And if the macro is used inside a if statement, this will be problematic:
if(bIsOk)
MY_MACRO(42) ;
This macro could be expanded as:
#define MY_MACRO(x) f(x) ; g(x)
if(bIsOk)
f(42) ; g(42) ; // was MY_MACRO(42) ;
The g function will be executed regardless of the value of bIsOk.
This means that we must have to add a scope to the macro:
#define MY_MACRO(x) { f(x) ; g(x) ; }
if(bIsOk)
{ f(42) ; g(42) ; } ; // was MY_MACRO(42) ;
Produce a valid code 2
If the macro is something like:
#define MY_MACRO(x) int i = x + 1 ; f(i) ;
We could have another problem in the following code:
void doSomething()
{
int i = 25 ;
MY_MACRO(32) ;
}
Because it would expand as:
void doSomething()
{
int i = 25 ;
int i = 32 + 1 ; f(i) ; ; // was MY_MACRO(32) ;
}
This code won't compile, of course. So, again, the solution is using a scope:
#define MY_MACRO(x) { int i = x + 1 ; f(i) ; }
void doSomething()
{
int i = 25 ;
{ int i = 32 + 1 ; f(i) ; } ; // was MY_MACRO(32) ;
}
The code behaves correctly again.
Combining semi-colon + scope effects?
There is one C/C++ idiom that produces this effect: The do/while loop:
do
{
// code
}
while(false) ;
The do/while can create a scope, thus encapsulating the macro's code, and needs a semi-colon in the end, thus expanding into code needing one.
The bonus?
The C++ compiler will optimize away the do/while loop, as the fact its post-condition is false is known at compile time. This means that a macro like:
#define MY_MACRO(x) \
do \
{ \
const int i = x + 1 ; \
f(i) ; g(i) ; \
} \
while(false)
void doSomething(bool bIsOk)
{
int i = 25 ;
if(bIsOk)
MY_MACRO(42) ;
// Etc.
}
will expand correctly as
void doSomething(bool bIsOk)
{
int i = 25 ;
if(bIsOk)
do
{
const int i = 42 + 1 ; // was MY_MACRO(42) ;
f(i) ; g(i) ;
}
while(false) ;
// Etc.
}
and is then compiled and optimized away as
void doSomething(bool bIsOk)
{
int i = 25 ;
if(bIsOk)
{
f(43) ; g(43) ;
}
// Etc.
}
#jfm3 - You have a nice answer to the question. You might also want to add that the macro idiom also prevents the possibly more dangerous (because there's no error) unintended behavior with simple 'if' statements:
#define FOO(x) f(x); g(x)
if (test) FOO( baz);
expands to:
if (test) f(baz); g(baz);
which is syntactically correct so there's no compiler error, but has the probably unintended consequence that g() will always be called.
The above answers explain the meaning of these constructs, but there is a significant difference between the two that was not mentioned. In fact, there is a reason to prefer the do ... while to the if ... else construct.
The problem of the if ... else construct is that it does not force you to put the semicolon. Like in this code:
FOO(1)
printf("abc");
Although we left out the semicolon (by mistake), the code will expand to
if (1) { f(X); g(X); } else
printf("abc");
and will silently compile (although some compilers may issue a warning for unreachable code). But the printf statement will never be executed.
do ... while construct does not have such problem, since the only valid token after the while(0) is a semicolon.
Explanation
do {} while (0) and if (1) {} else are to make sure that the macro is expanded to only 1 instruction. Otherwise:
if (something)
FOO(X);
would expand to:
if (something)
f(X); g(X);
And g(X) would be executed outside the if control statement. This is avoided when using do {} while (0) and if (1) {} else.
Better alternative
With a GNU statement expression (not a part of standard C), you have a better way than do {} while (0) and if (1) {} else to solve this, by simply using ({}):
#define FOO(X) ({f(X); g(X);})
And this syntax is compatible with return values (note that do {} while (0) isn't), as in:
return FOO("X");
While it is expected that compilers optimize away the do { ... } while(false); loops, there is another solution which would not require that construct. The solution is to use the comma operator:
#define FOO(X) (f(X),g(X))
or even more exotically:
#define FOO(X) g((f(X),(X)))
While this will work well with separate instructions, it will not work with cases where variables are constructed and used as part of the #define :
#define FOO(X) (int s=5,f((X)+s),g((X)+s))
With this one would be forced to use the do/while construct.
Jens Gustedt's P99 preprocessor library (yes, the fact that such a thing exists blew my mind too!) improves on the if(1) { ... } else construct in a small but significant way by defining the following:
#define P99_NOP ((void)0)
#define P99_PREFER(...) if (1) { __VA_ARGS__ } else
#define P99_BLOCK(...) P99_PREFER(__VA_ARGS__) P99_NOP
The rationale for this is that, unlike the do { ... } while(0) construct, break and continue still work inside the given block, but the ((void)0) creates a syntax error if the semicolon is omitted after the macro call, which would otherwise skip the next block. (There isn't actually a "dangling else" problem here, since the else binds to the nearest if, which is the one in the macro.)
If you are interested in the sorts of things that can be done more-or-less safely with the C preprocessor, check out that library.
For some reasons I can't comment on the first answer...
Some of you showed macros with local variables, but nobody mentioned that you can't just use any name in a macro! It will bite the user some day! Why? Because the input arguments are substituted into your macro template. And in your macro examples you've use the probably most commonly used variabled name i.
For example when the following macro
#define FOO(X) do { int i; for (i = 0; i < (X); ++i) do_something(i); } while (0)
is used in the following function
void some_func(void) {
int i;
for (i = 0; i < 10; ++i)
FOO(i);
}
the macro will not use the intended variable i, that is declared at the beginning of some_func, but the local variable, that is declared in the do ... while loop of the macro.
Thus, never use common variable names in a macro!
I don't think it was mentioned so consider this
while(i<100)
FOO(i++);
would be translated into
while(i<100)
do { f(i++); g(i++); } while (0)
notice how i++ is evaluated twice by the macro. This can lead to some interesting errors.
In many C/C++ macros I'm seeing the code of the macro wrapped in what seems like a meaningless do while loop. Here are examples.
#define FOO(X) do { f(X); g(X); } while (0)
#define FOO(X) if (1) { f(X); g(X); } else
I can't see what the do while is doing. Why not just write this without it?
#define FOO(X) f(X); g(X)
The do ... while and if ... else are there to make it so that a
semicolon after your macro always means the same thing. Let's say you
had something like your second macro.
#define BAR(X) f(x); g(x)
Now if you were to use BAR(X); in an if ... else statement, where the bodies of the if statement were not wrapped in curly brackets, you'd get a bad surprise.
if (corge)
BAR(corge);
else
gralt();
The above code would expand into
if (corge)
f(corge); g(corge);
else
gralt();
which is syntactically incorrect, as the else is no longer associated with the if. It doesn't help to wrap things in curly braces within the macro, because a semicolon after the braces is syntactically incorrect.
if (corge)
{f(corge); g(corge);};
else
gralt();
There are two ways of fixing the problem. The first is to use a comma to sequence statements within the macro without robbing it of its ability to act like an expression.
#define BAR(X) f(X), g(X)
The above version of bar BAR expands the above code into what follows, which is syntactically correct.
if (corge)
f(corge), g(corge);
else
gralt();
This doesn't work if instead of f(X) you have a more complicated body of code that needs to go in its own block, say for example to declare local variables. In the most general case the solution is to use something like do ... while to cause the macro to be a single statement that takes a semicolon without confusion.
#define BAR(X) do { \
int i = f(X); \
if (i > 4) g(i); \
} while (0)
You don't have to use do ... while, you could cook up something with if ... else as well, although when if ... else expands inside of an if ... else it leads to a "dangling else", which could make an existing dangling else problem even harder to find, as in the following code.
if (corge)
if (1) { f(corge); g(corge); } else;
else
gralt();
The point is to use up the semicolon in contexts where a dangling semicolon is erroneous. Of course, it could (and probably should) be argued at this point that it would be better to declare BAR as an actual function, not a macro.
In summary, the do ... while is there to work around the shortcomings of the C preprocessor. When those C style guides tell you to lay off the C preprocessor, this is the kind of thing they're worried about.
Macros are copy/pasted pieces of text the pre-processor will put in the genuine code; the macro's author hopes the replacement will produce valid code.
There are three good "tips" to succeed in that:
Help the macro behave like genuine code
Normal code is usually ended by a semi-colon. Should the user view code not needing one...
doSomething(1) ;
DO_SOMETHING_ELSE(2) // <== Hey? What's this?
doSomethingElseAgain(3) ;
This means the user expects the compiler to produce an error if the semi-colon is absent.
But the real real good reason is that at some time, the macro's author will perhaps need to replace the macro with a genuine function (perhaps inlined). So the macro should really behave like one.
So we should have a macro needing semi-colon.
Produce a valid code
As shown in jfm3's answer, sometimes the macro contains more than one instruction. And if the macro is used inside a if statement, this will be problematic:
if(bIsOk)
MY_MACRO(42) ;
This macro could be expanded as:
#define MY_MACRO(x) f(x) ; g(x)
if(bIsOk)
f(42) ; g(42) ; // was MY_MACRO(42) ;
The g function will be executed regardless of the value of bIsOk.
This means that we must have to add a scope to the macro:
#define MY_MACRO(x) { f(x) ; g(x) ; }
if(bIsOk)
{ f(42) ; g(42) ; } ; // was MY_MACRO(42) ;
Produce a valid code 2
If the macro is something like:
#define MY_MACRO(x) int i = x + 1 ; f(i) ;
We could have another problem in the following code:
void doSomething()
{
int i = 25 ;
MY_MACRO(32) ;
}
Because it would expand as:
void doSomething()
{
int i = 25 ;
int i = 32 + 1 ; f(i) ; ; // was MY_MACRO(32) ;
}
This code won't compile, of course. So, again, the solution is using a scope:
#define MY_MACRO(x) { int i = x + 1 ; f(i) ; }
void doSomething()
{
int i = 25 ;
{ int i = 32 + 1 ; f(i) ; } ; // was MY_MACRO(32) ;
}
The code behaves correctly again.
Combining semi-colon + scope effects?
There is one C/C++ idiom that produces this effect: The do/while loop:
do
{
// code
}
while(false) ;
The do/while can create a scope, thus encapsulating the macro's code, and needs a semi-colon in the end, thus expanding into code needing one.
The bonus?
The C++ compiler will optimize away the do/while loop, as the fact its post-condition is false is known at compile time. This means that a macro like:
#define MY_MACRO(x) \
do \
{ \
const int i = x + 1 ; \
f(i) ; g(i) ; \
} \
while(false)
void doSomething(bool bIsOk)
{
int i = 25 ;
if(bIsOk)
MY_MACRO(42) ;
// Etc.
}
will expand correctly as
void doSomething(bool bIsOk)
{
int i = 25 ;
if(bIsOk)
do
{
const int i = 42 + 1 ; // was MY_MACRO(42) ;
f(i) ; g(i) ;
}
while(false) ;
// Etc.
}
and is then compiled and optimized away as
void doSomething(bool bIsOk)
{
int i = 25 ;
if(bIsOk)
{
f(43) ; g(43) ;
}
// Etc.
}
#jfm3 - You have a nice answer to the question. You might also want to add that the macro idiom also prevents the possibly more dangerous (because there's no error) unintended behavior with simple 'if' statements:
#define FOO(x) f(x); g(x)
if (test) FOO( baz);
expands to:
if (test) f(baz); g(baz);
which is syntactically correct so there's no compiler error, but has the probably unintended consequence that g() will always be called.
The above answers explain the meaning of these constructs, but there is a significant difference between the two that was not mentioned. In fact, there is a reason to prefer the do ... while to the if ... else construct.
The problem of the if ... else construct is that it does not force you to put the semicolon. Like in this code:
FOO(1)
printf("abc");
Although we left out the semicolon (by mistake), the code will expand to
if (1) { f(X); g(X); } else
printf("abc");
and will silently compile (although some compilers may issue a warning for unreachable code). But the printf statement will never be executed.
do ... while construct does not have such problem, since the only valid token after the while(0) is a semicolon.
Explanation
do {} while (0) and if (1) {} else are to make sure that the macro is expanded to only 1 instruction. Otherwise:
if (something)
FOO(X);
would expand to:
if (something)
f(X); g(X);
And g(X) would be executed outside the if control statement. This is avoided when using do {} while (0) and if (1) {} else.
Better alternative
With a GNU statement expression (not a part of standard C), you have a better way than do {} while (0) and if (1) {} else to solve this, by simply using ({}):
#define FOO(X) ({f(X); g(X);})
And this syntax is compatible with return values (note that do {} while (0) isn't), as in:
return FOO("X");
While it is expected that compilers optimize away the do { ... } while(false); loops, there is another solution which would not require that construct. The solution is to use the comma operator:
#define FOO(X) (f(X),g(X))
or even more exotically:
#define FOO(X) g((f(X),(X)))
While this will work well with separate instructions, it will not work with cases where variables are constructed and used as part of the #define :
#define FOO(X) (int s=5,f((X)+s),g((X)+s))
With this one would be forced to use the do/while construct.
Jens Gustedt's P99 preprocessor library (yes, the fact that such a thing exists blew my mind too!) improves on the if(1) { ... } else construct in a small but significant way by defining the following:
#define P99_NOP ((void)0)
#define P99_PREFER(...) if (1) { __VA_ARGS__ } else
#define P99_BLOCK(...) P99_PREFER(__VA_ARGS__) P99_NOP
The rationale for this is that, unlike the do { ... } while(0) construct, break and continue still work inside the given block, but the ((void)0) creates a syntax error if the semicolon is omitted after the macro call, which would otherwise skip the next block. (There isn't actually a "dangling else" problem here, since the else binds to the nearest if, which is the one in the macro.)
If you are interested in the sorts of things that can be done more-or-less safely with the C preprocessor, check out that library.
For some reasons I can't comment on the first answer...
Some of you showed macros with local variables, but nobody mentioned that you can't just use any name in a macro! It will bite the user some day! Why? Because the input arguments are substituted into your macro template. And in your macro examples you've use the probably most commonly used variabled name i.
For example when the following macro
#define FOO(X) do { int i; for (i = 0; i < (X); ++i) do_something(i); } while (0)
is used in the following function
void some_func(void) {
int i;
for (i = 0; i < 10; ++i)
FOO(i);
}
the macro will not use the intended variable i, that is declared at the beginning of some_func, but the local variable, that is declared in the do ... while loop of the macro.
Thus, never use common variable names in a macro!
I don't think it was mentioned so consider this
while(i<100)
FOO(i++);
would be translated into
while(i<100)
do { f(i++); g(i++); } while (0)
notice how i++ is evaluated twice by the macro. This can lead to some interesting errors.