举例说明 C 预处理器中 # 和 ## 的未指定相对计算顺序

问：

关于已接受答案的一些评论在本问题帖子的底部。

问题陈述

根据 C 标准（C17 草案，6.10.3.2 ¶2）：

[the] 和运算符的计算顺序未指定。###

我正在寻找一个示例，其中此评估顺序很重要，并且没有其他未定义行为的实例，也没有错误。

在花了一些时间讨论这个问题之后，我怀疑以下方法可能会起作用：

#define PRECEDENCETEST(a, b, c)  # a ## b

PRECEDENCETEST(c, , d)

（请注意，预处理器可以按如下方式运行：或 （GCC）、（MSVC）;有关可编译的虚拟示例，请参阅下文。另请注意，空宏参数仅在 C99 之后才合法。cppgcc -Ecl /E

我的问题是：根据 C 标准，这是否真的可以作为 # 和 ## 的相对评估顺序产生合法输出的示例？正如我在这篇文章底部所解释的那样，如果我理解正确的话，答案可能取决于标准是否允许之后的令牌最终与最初指定的令牌不同。#

如果答案是“是（因为...）”，那么我们找到了一个例子！如果答案是“不，你的例子不起作用（因为......）”，那么我稍后会想出一种方法来征求更好的例子。

（请注意，该标准不要求编译器对 and 运算符具有绝对相对计算顺序。顺序可以是：从左到右，从右到左，遵循其他逻辑，或者完全随机。###

文档

较旧的 GCC 文档（似乎最高为 6.5 版）指出：

该标准没有规定“”运算符链的计算顺序，也没有规定“”是在“”之前、之后还是与“”同时计算。因此，您不应编写任何依赖于任何特定顺序的代码。如果需要，可以通过适当使用嵌套宏来保证排序。#####

例如，粘贴参数 ''、'' 和 ''。这对于从左到右的粘贴来说很好，但从右到左的粘贴会产生无效的标记 ''。1e-2e-2

GCC 3.0 同时计算 '' 和 ''，严格从左到右。旧版本首先计算所有 '' 运算符，然后以不可靠的顺序计算所有 '' 运算符。######

（对于中间段落中的 -only 示例（即：）：不是有效的浮点常数（C17 draft，6.4.4.2），但它是有效的 pp 数（“预处理数”;C17 草案，6.4.8），因为鞋底是有效的标识符非数字。（预处理数字的存在是为了“将预处理器与数字常量的全部复杂性隔离开来”;参见 GNU 文档了解其 C 预处理器。也就是说，一个更好的例子是（对从左到右有效，但不适用于从右到左的令牌连接），改编自这个 MISRA 讨论。##1##e##-21ee2##.##e3

就其价值而言，维基百科在其关于C预处理器的文章中声称以下内容：

类似宏扩展的扩展发生在以下阶段：

1. 字符串化操作将替换为其参数替换列表的文本表示形式（不执行扩展）。
2. 参数将替换为其替换列表（不执行扩展）。
3. 串联运算将替换为两个操作数的串联结果（不扩展生成的标记）。
4. 源自参数的令牌将展开。
5. 生成的令牌将照常展开。

但是，我在 C 标准或 GNU 的 CPP（C 预处理器，GCC 的一部分）文档中找不到对这种特定评估顺序的支持，截至提出这个问题时，其最新文档（GCC 13.2）在这里。

最重要的是，上述来源（包括 C17 标准）都没有提供类似函数的宏的示例，该宏的计算结果会根据宏替换列表中 # 和 ## 的相对优先级而有所不同。

我正在寻找不会导致其他未定义行为或错误的示例，因为看似有效的宏是难以发现的错误的潜在来源。在这方面，重要的是以下两个约束：

• “如果 [来自运算符] 的替换不是有效的字符串文字，则行为未定义。”（C17 草案，6.10.3.2 ¶2）#
• “如果 [令牌连接] 的结果不是有效的预处理令牌，则行为未定义。”（C17 草案，6.10.3.3 ¶3）##

查找示例

寻找合适的例子结果出乎意料地棘手。

首先，字符串文字（C17 draft，6.4.5）——我们正在考虑，因为它们是应用的结果——几乎不能与其他任何内容连接起来：###

• ##不能用于连接两个字符串文字，因为类似的东西不是有效的预处理标记（C17 草案，6.4 ¶1）。这里需要注意的是，基于标记的串联与翻译阶段 6（C17 草案，5.1.1.2 ¶1）中的字符串文字串联不同，后者将合并并合并为 ."abc""def"##"abc""def""abcdef"
• 字符串文字可以选择以编码前缀 （， ， ， ） 开头，但编写这样的替换列表会导致有效的预处理标记需要 s 的微妙平衡（除了启动预处理指令或在字符串或字符文字中之外，它只能作为预处理标记和它们本身的一部分存在），我无法实现。例如，在任一计算顺序下生成（假设字符串化运算符可以合法地从应用 中得到），我不确定这个示例是否可以根据计算顺序演变成一个产生两个不同的有效结果。u8uUL[...] ## # b####

  #define TEST(a, b)  a ## # b
  TEST(, c)
  

  "c"###

此外，类似的东西不起作用，因为在这个表达式中，“”和“”部分是独立的。a ## b # ca ## b# c

但是，似乎以下方法可能有效：

#include <stdio.h>

#define PRECEDENCETEST(a, b, c)  # a ## b

int main(void) {
    printf("%s\n", PRECEDENCETEST(c, , d));

    return 0;
}

案例 A：对于 GCC 和 MSVC，我得到的输出对应于 #-before-## 的评估顺序：c

PRECEDENCETEST(c, , d)
# a ## b
"c" ## b
"c" ## <placemarker>
"c"

（地标预处理标记表示与 相邻的空宏参数。（C17 草案，6.10.3.3 ¶2））##

案例 B：##-before-# 评估顺序将给出以下内容：

PRECEDENCETEST(c, , d)
# a ## b
# c ## <placemarker>
# c
"d"

也就是说，程序的输出必须是 。或者会吗？最后一步假定它不仅可以对原始替换列表中的参数进行操作，还可以对应用 .需要注意的是，以下约束（C17 草案，6.10.3.2 ¶1）d###

类似函数的宏的替换列表中的每个 # 预处理标记后应跟一个参数，作为替换列表中的下一个预处理标记。[这不适用于类似对象的宏。

没有被违反 - 只是在这个例子中，实际参数最终是与替换列表（）中指定的参数不同的参数（）。#ca

关于接受答案的评论：

• 我相信公认的答案代表了对标准最明智的解释。事实上，该标准的编写方式应该迫使任何读者得出相同的结论。

• 但是，我确实相信该标准的作者没有考虑清楚。究其原因，是这样的：结合

  1. 接受的答案和
  2. 我的思考（在我的问题帖子的“寻找示例”部分开头的项目符号中）关于两个字符串文字的串联##

  相对接近于证明

  不存在以下情况：以两种不同的方式解析相同的输入，仅在应用顺序上有所不同，从而导致两种不同的输出可能性，这些输出既不调用错误（例如违反预处理器约束），也不调用未定义的行为。###

  因为，如果确实没有这样的情况，C标准的作者可以简单地规定“之前”，因为添加这样的规定将无法影响现有的有效/非UB程序。（有关更多详细信息/要点，请参阅我与回答者的讨论。###

  同样，如果 C 标准像公认的答案所暗示的那样清晰，为什么 GCC 维护者和文档作者（他们显然对这个问题进行了一些思考）没有提供具有类似结论（或其他对比示例）的相关评论？