Why are there sometimes meaningless do/while and i

hansfly

http://stackoverflow.com/questions/154136/why-are-there-sometimes-meaningless-dowhile-and-ifelse-statements-in-cc-macros

Answer:
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 the following is also 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.
               
               
               

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u1/34411/showart_2108107.html