解释

执行{}while(0)和if (1) {} else确保宏被扩展到只有一条指令。否则:

if (something)
  FOO(X); 

将扩大为:

if (something)
  f(X); g(X); 

g(X)将在if控制语句之外执行。当使用do {} while(0)和if (1) {} else时，可以避免这种情况。

更好的选择

使用GNU语句表达式(不是标准C的一部分)，你有一个比{}while(0)和if (1) {} else更好的方法来解决这个问题，只需使用({}):

#define FOO(X) ({f(X); g(X);})

并且此语法与返回值兼容(注意do {} while(0)不兼容)，例如:

return FOO("X");

由于某些原因，我不能评论第一个答案……

有些人展示了带局部变量的宏，但没有人提到不能在宏中使用任何名称!它总有一天会伤害用户!为什么?因为输入参数被替换到宏模板中。在你的宏例子中，你使用了最常用的变量名i。

例如下面的宏

#define FOO(X) do { int i; for (i = 0; i < (X); ++i) do_something(i); } while (0)

在以下函数中使用

void some_func(void) {
    int i;
    for (i = 0; i < 10; ++i)
        FOO(i);
}

该宏将不会使用some_func开头声明的预期变量i，而是在do…宏的While循环。

因此，永远不要在宏中使用通用变量名!

做…如果……还有别的方法可以让 宏后面的分号总是同样的意思。比如说你 就像你的第二个宏。

#define BAR(X) f(x); g(x)

如果你用BAR(X);如果…Else语句，if语句的语句体没有被花括号括起来，你会得到一个糟糕的惊喜。

if (corge)
  BAR(corge);
else
  gralt();

上面的代码将展开为

if (corge)
  f(corge); g(corge);
else
  gralt();

这在语法上是不正确的，因为else不再与if关联。在宏中用大括号括起来没有帮助，因为大括号后面的分号在语法上是不正确的。

if (corge)
  {f(corge); g(corge);};
else
  gralt();

解决这个问题有两种方法。第一种方法是在宏中使用逗号对语句进行排序，而不剥夺它像表达式一样工作的能力。

#define BAR(X) f(X), g(X)

上面版本的bar bar将上面的代码扩展为下面的代码，这在语法上是正确的。

if (corge)
  f(corge), g(corge);
else
  gralt();

如果你有一个更复杂的代码体而不是f(X)这是行不通的，它需要放在自己的代码块中，比如声明局部变量。在大多数情况下，解决方案是使用do…而使宏成为一个单独的语句，使用分号而不会造成混淆。

#define BAR(X) do { \
  int i = f(X); \
  if (i > 4) g(i); \
} while (0)

你不必用do…不过，你可以用if…Else也是，尽管when if…Else扩展到if…否则它会导致“悬空Else”，这可能会使现有的悬空Else问题更难找到，如下面的代码所示。

if (corge)
  if (1) { f(corge); g(corge); } else;
else
  gralt();

重点是在悬空分号错误的上下文中使用分号。当然，在这一点上，可以(也可能应该)认为将BAR声明为一个实际的函数而不是宏会更好。

总之，做…而有工作围绕C预处理器的缺点。当那些C风格指南告诉你不要使用C预处理器时，这就是他们所担心的事情。

上述答案解释了这些结构的含义，但两者之间有一个未被提及的显著差异。事实上，有一个理由更喜欢做…而如果…其他结构。

如果……Else结构的特点是它不强制你输入分号。就像下面的代码:

FOO(1)
printf("abc");

尽管我们(错误地)漏掉了分号，但代码将扩展为

if (1) { f(X); g(X); } else
printf("abc");

并且将静默地编译(尽管一些编译器可能会对不可访问的代码发出警告)。但是printf语句永远不会被执行。

做……While构造就没有这样的问题，因为While(0)后面唯一有效的标记是分号。

Jens Gustedt的P99预处理器库(是的，这样一个东西的存在也让我大吃一惊!)改进了if(1){…} else构造了一个小而重要的方法，定义如下:

#define P99_NOP ((void)0)
#define P99_PREFER(...) if (1) { __VA_ARGS__ } else
#define P99_BLOCK(...) P99_PREFER(__VA_ARGS__) P99_NOP

这样做的基本原理是，与do{…} while(0) construct, break和continue仍然在给定的块内工作，但是((void)0)如果在宏调用后省略了分号，将会创建一个语法错误，否则将跳过下一个块。(这里实际上不存在“悬空else”问题，因为else绑定到最近的if，也就是宏中的if。)

如果您对C预处理器可以或多或少安全地完成的事情感兴趣，请查看该库。

@jfm3 -你对这个问题的回答很好。你可能还想补充一点，宏习语还可以通过简单的'if'语句防止可能更危险的(因为没有错误)意外行为:

#define FOO(x)  f(x); g(x)

if (test) FOO( baz);

扩展:

if (test) f(baz); g(baz);

这在语法上是正确的，因此没有编译器错误，但可能会产生意想不到的后果，即总是会调用g()。