为什么在宏中使用明显无意义的 do-while 和 if-else 语句?

发布于 2024-07-05 17:22:35 字数 295 浏览 10 评论 0原文

在许多 C/C++ 宏中,我看到宏的代码包裹在看似无意义的 do while 循环中。 以下是示例。

#define FOO(X) do { f(X); g(X); } while (0)
#define FOO(X) if (1) { f(X); g(X); } else

我看不到 do while 正在做什么。 为什么不直接写这个呢?

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

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)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(9

記憶穿過時間隧道 2024-07-12 17:22:35

do ... whileif ... else 的作用是让
宏后面的分号总是表示相同的意思。 就说你吧
有类似你的第二个宏的东西。

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

现在,如果您要在 if ... else 语句中使用 BAR(X);,其中 if 语句的主体未包含在大括号中,那么您'会得到一个糟糕的惊喜。

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

上面的代码将扩展为在

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

语法上不正确的which,因为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 ... while 之类的内容来使宏成为带有分号的单个语句,而不会造成混淆。

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

您不必使用 do ... while,您也可以使用 if ... else 来编写一些东西,尽管当 if ... elseif ... else 内部展开,它会导致“dangling else”,这可能会使现有的 dangling else 问题更难找到,如以下代码所示。

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

重点是在悬空分号错误的情况下用完分号。 当然,此时可能(并且可能应该)争论将 BAR 声明为实际函数而不是宏会更好。

总之,do ... while 的作用是解决 C 预处理器的缺点。 当那些 C 风格指南告诉您放弃 C 预处理器时,他们担心的是这种事情。

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.

话少心凉 2024-07-12 17:22:35

宏是预处理器将复制/粘贴的文本片段放入真正的代码中; 该宏的作者希望替换后能够生成有效的代码。

要成功做到这一点,有三个很好的“技巧”:

帮助宏像真正的代码一样运行

普通代码通常以分号结尾。 如果用户查看不需要分号的代码...

doSomething(1) ;
DO_SOMETHING_ELSE(2)  // <== Hey? What's this?
doSomethingElseAgain(3) ;

这意味着用户希望编译器在不存在分号的情况下产生错误。

但真正好的理由是,在某些时候,宏的作者可能需要用真正的函数(可能是内联的)替换宏。 因此,宏应该真正表现得像一个宏。

所以我们应该有一个需要分号的宏。

生成有效代码

正如 jfm3 的答案所示,有时宏包含多个指令。 如果在 if 语句中使用该宏,则会出现问题:

if(bIsOk)
   MY_MACRO(42) ;

该宏可以扩展为:

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

if(bIsOk)
   f(42) ; g(42) ; // was MY_MACRO(42) ;

无论 bIsOk 的值如何,都会执行 g 函数。

这意味着我们必须向宏添加一个作用域:

#define MY_MACRO(x) { f(x) ; g(x) ; }

if(bIsOk)
   { f(42) ; g(42) ; } ; // was MY_MACRO(42) ;

生成有效的代码 2

如果宏类似于:

#define MY_MACRO(x) int i = x + 1 ; f(i) ;

我们在以下代码中可能会遇到另一个问题:

void doSomething()
{
    int i = 25 ;
    MY_MACRO(32) ;
}

因为它会扩展为:

void doSomething()
{
    int i = 25 ;
    int i = 32 + 1 ; f(i) ; ; // was MY_MACRO(32) ;
}

此代码将无法编译,课程。 因此,解决方案再次使用范围:

#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) ;
}

代码再次正常运行。

结合分号+作用域效果?

有一种 C/C++ 习惯用法可以产生这种效果: do/while 循环:

do
{
    // code
}
while(false) ;

do/while 可以创建一个作用域,从而封装宏的代码,并且最后需要一个分号,从而扩展到需要分号的代码。

奖金?

C++ 编译器将优化 do/while 循环,因为在编译时就知道其后置条件为 false。 这意味着像这样的宏:

#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.
}

将正确扩展为

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.
}

,然后被编译和优化为

void doSomething(bool bIsOk)
{
   int i = 25 ;

   if(bIsOk)
   {
      f(43) ; g(43) ;
   }

   // Etc.
}

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.
}
っ左 2024-07-12 17:22:35

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

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

if (test) FOO( baz);

扩展为:

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

这在语法上是正确的,因此不会出现编译器错误,但可能会产生意外的后果g() 总是会被调用。

@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.

东京女 2024-07-12 17:22:35

上面的答案解释了这些结构的含义,但是两者之间存在未提及的显着差异。 事实上,我们有理由更喜欢 do ... while 而不是 if ... else 结构。

if ... else 构造的问题是它不会强制您输入分号。 就像这段代码一样:

FOO(1)
printf("abc");

虽然我们漏掉了分号(错误地),但代码将扩展为

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

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

do ... while 构造不存在这样的问题,因为 while(0) 之后的唯一有效标记是分号。

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.

别忘他 2024-07-12 17:22:35

说明

do {} while (0)if (1) {} else 是为了确保宏仅扩展为 1 条指令。 否则:

if (something)
    FOO(X); 

将扩展为:

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

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


使用

GNU 语句表达式< /a> (不是标准 C 的一部分),您有比 do {} while (0)if (1) {} else 更好的方法来解决这个问题,只需使用 ({})

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

并且此语法与返回值兼容(请注意 do {} while (0) 不兼容),如下所示:

return FOO("X");

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");
不及他 2024-07-12 17:22:35

虽然预计编译器会优化 do { ... } while(false); 循环,但还有另一种解决方案不需要该构造。 解决方案是使用逗号运算符:

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

或者更奇特的是:

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

虽然这对于单独的指令可以很好地工作,但它不适用于构造变量并将其用作 #define 的一部分的情况

#define FOO(X) (int s=5,f((X)+s),g((X)+s))

:这将被迫使用 do/while 结构。

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.

在巴黎塔顶看东京樱花 2024-07-12 17:22:35

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) 构造,breakcontinue 仍然在给定块内工作,但是 ((void)0)如果宏调用后省略分号,则会产生语法错误,否则会跳过下一个块。 (这里实际上不存在“悬空 else”问题,因为 else 绑定到最近的 if,即宏中的那个。)

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

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.

迷爱 2024-07-12 17:22:35

由于某些原因,我无法对第一个答案发表评论...

你们中的一些人展示了带有局部变量的宏,但没有人提到您不能在宏中使用任何名称! 总有一天它会咬住用户! 为什么? 因为输入参数被替换到您的宏模板中。 在您的宏示例中,您使用了可能最常用的变量名称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 循环中声明的局部变量。

因此,切勿在宏中使用通用变量名!

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!

隱形的亼 2024-07-12 17:22:35

我不认为它被提及,所以考虑这

while(i<100)
  FOO(i++);

将被转换为

while(i<100)
  do { f(i++); g(i++); } while (0)

注意 i++ 如何被宏计算两次。 这可能会导致一些有趣的错误。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文