C ++嵌套11宏调用？ [英] C++11 nested macro invocation?

问题描述

报告说，在C ++的std 16.3.4：

It says in C++ std 16.3.4:

由此产生的preprocessing令牌序列[从宏调用替换]
  重新扫描，与源文件的所有后续preprocessing令牌一起，为更多的宏名
  更换。

The resulting preprocessing token sequence [from a macro invocation replacement] is rescanned, along with all subsequent preprocessing tokens of the source file, for more macro names to replace.

如果宏被替换该扫描替换列表的过程中发现的名称（不包括
  源文件的preprocessing令牌的其余部分），且未被替换。

If the name of the macro being replaced is found during this scan of the replacement list (not including the rest of the source file’s preprocessing tokens), it is not replaced.

此外，如果任何嵌套替换遇到宏的名称所取代，所以不能更换。

Furthermore, if any nested replacements encounter the name of the macro being replaced, it is not replaced.

这些nonreplaced宏的名称preprocessing令牌不再提供进一步的更换，即使他们以后（重新）审查背景
  其中，宏观名preprocessing令牌否则将被取代。

These nonreplaced macro name preprocessing tokens are no longer available for further replacement even if they are later (re)examined in contexts in which that macro name preprocessing token would otherwise have been replaced.

究竟是一个嵌套的宏替换？

具体考虑：

#define f(x) 1 x
#define g(x) 2 x

g(f)(g)(3)

我本来期望如下：

I would have expected the following:

g(f)(g)(3)    <-- first replacement of g, ok
2 f(g)(3)     <-- nested replacement of f, ok
2 1 g(3)      <-- second nested replacement of g, don't replace, stop

但是GCC意外地推进第二替换克，生产：

However gcc unexpectedly goes ahead with the second replacement of g, producing:

2 1 2 3

任何想法？

更新：

在大量的研究，让我明确了一个简单的例子此问题：

After much research, let me clear up this issue with a simpler example:

#define A(x) B
#define B(x) A(x)

A(i)(j)

此扩展如下：

A(i)(j)
B(j)
A(j)

该标准没有规定是否 A（J）应扩大到 B 与否。该委员会决定继续这种方式，因为现实世界的计划预计不会依赖此行为，这样既让 A（J）未展开和扩大 A（j）条到 B 被认为是符合。

The standard does not specify whether A(j) should be expanded to B or not. The committee decided to leave it this way because real world programs are not expected to depend on this behavior, so both leaving A(j) unexpanded and expanding A(j) to B are considered conformant.

推荐答案

这说明了原意，为什么没有说明已被添加到这个问题的标准：

This explains the original intent, and why no clarifications have been added to the standard about this subject:

<一个href=\"http://open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#268\">http://open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#268

栏目：16.3.4 [cpp.rescan＆NBSP; ＆NBSP; 状态：开＆NBSP; ＆NBSP; 发布：Bjarne的Stroustrup的＆NBSP; ＆NBSP; 日期：18 2001年1月

268. Macro name suppression in rescanned replacement text

Section: 16.3.4 [cpp.rescan]     Status: open     Submitter: Bjarne Stroustrup     Date: 18 Jan 2001

这是不是从标准明确下面的例子的结果应该是什么：

It is not clear from the Standard what the result of the following example should be:

#define NIL(xxx) xxx
#define G_0(arg) NIL(G_1)(arg)
#define G_1(arg) NIL(arg)
G_0(42)

  
  

从标准中的有关内容在16.3.4找到[cpp.rescan]第2款规定：

The relevant text from the Standard is found in 16.3.4 [cpp.rescan] paragraph 2:

[剪断]

G0扩张的序列（42）如下：

G0(42)
NIL(G_1)(42)
G_1(42)
NIL(42)

  
  

问题是，在这个序列中的最后一行用 NIL 的是否符合引用的文字在非更换。如果是的话，结果将是 NIL（42）。如果没有，那么结果将是根本 42 。

The question is whether the use of NIL in the last line of this sequence qualifies for non-replacement under the cited text. If it does, the result will be NIL(42). If it does not, the result will be simply 42.

在这个文本中的J11委员会的初衷是，该结果应该是 42 ，就证明了原来的伪code说明由戴维·普罗瑟，它的作者提供的替换算法。的英文说明，但省略了一些伪code的细微之处，因此可以说是给出了这种情况下，不正确的答案。

The original intent of the J11 committee in this text was that the result should be 42, as demonstrated by the original pseudo-code description of the replacement algorithm provided by Dave Prosser, its author. The English description, however, omits some of the subtleties of the pseudo-code and thus arguably gives an incorrect answer for this case.

的建议的解决方案（麦克 - 米勒）的：[剪断]

早在1980年就被几个人WG14，有不更换连篇产生伪code中的尝试之间微小差异的理解。 该委员会的决定是野生没有现实的方案将冒险进入这个领域，并试图减少不确定性是不值得改变的实施或计划的一致性状态的风险。

Back in the 1980's it was understood by several WG14 people that there were tiny differences between the "non-replacement" verbiage and the attempts to produce pseudo-code. The committee's decision was that no realistic programs "in the wild" would venture into this area, and trying to reduce the uncertainties is not worth the risk of changing conformance status of implementations or programs.

这篇关于C ++嵌套11宏调用？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！