标准 C++ 预处理器综合报告

第 1 节：预处理器在 C++ 编译生态系统中的角色

1.1 核心功能：一个基于文本的转换引擎

C++ 预处理器（CPP）是 C++ 编译工具链中一个至关重要但又常被误解的组件。其核心本质是一个文本处理工具，它在编译器对源代码进行语法和语义分析之前，对源文件进行一系列的转换操作。必须深刻理解的是，预处理器对 C++ 语言的复杂结构——如类型系统、作用域规则或类封装——一无所知。它的操作完全是词法层面的：文件包含本质上是文本复制粘贴，宏扩展是简单的查找替换，而条件编译则是根据特定条件移除文本块。

这种与语言本身解耦的特性，既是预处理器强大灵活性的来源，也是其诸多陷阱和危险的根源。预处理阶段的输出是一个经过完全展开的、不含任何预处理指令的“纯” C++ 源文件，这个文件通常被称为“翻译单元”（translation unit），在某些工具链中可以保存为扩展名为 .i 的中间文件。随后，这个翻译单元才被送入编译器进行真正的语法分析、编译和最终的链接。这种工作模式揭示了一个基本事实：预处理器不是 C++ 编译器的延伸，而是一个为编译器准备输入数据的独立工具。开发者遇到的许多与预处理器相关的、难以调试的错误，都源于一个根本性的误解——试图从一个纯文本处理工具中寻求语言级的语义保证。

1.2 历史渊源与设计哲学

预处理器的历史可以追溯到 1973 年左右，它在 C++ 诞生前约十年就被引入到 C 语言中。其设计受到了当时其他编程语言（如 BCPL 和 PL/I）中文件包含机制的启发。最初的预处理器功能非常精简和务实，仅包含两个核心指令：用于文件包含的#include 和用于无参数字符串替换的 #define。

这段历史背景对于理解预处理器的本质至关重要。它并非为 C++ 的面向对象和泛型编程范式而生，其设计哲学——直接、无语义的文本操作——与现代 C++ 所倡导的类型安全、封装和作用域控制等核心原则常常背道而驰。因此，预处理器在 C++ 中更像是一个历史遗留的、功能强大的工具，而不是一个与语言特性原生集成的部分。

1.3 融入 C++ 编译模型：翻译的前四个阶段

C++ 标准将编译过程严谨地定义为一系列“翻译阶段”。预处理器的工作精确地对应了标准中定义的前四个阶段，这构成了编译流程的序幕。

• 阶段 1：三字符组（Trigraph）替换。这是一个历史遗留特性，旨在解决某些早期字符集缺少 C++ 必需符号（如 #, [ 等）的问题。随着现代编码标准的普及，三字符组已基本废弃，并分别在 C++17 中被弃用，在 C23 标准中被正式移除。
• 阶段 2：行拼接（Line Splicing）。预处理器会将以反斜杠（\）结尾的物理代码行与其下一行拼接成一个单一的逻辑行。这个机制是实现多行宏定义的基础。
• 阶段 3：词法化（Tokenization）。在此阶段，源代码文件被分解为一系列预处理“令牌”（token）和空白字符。至关重要的是，所有注释都会被替换为一个空格。预处理器后续的操作对象是这些令牌流，而非原始的字符序列。
• 阶段 4：宏扩展与指令处理。这是预处理的核心阶段。预处理器执行所有以 # 开头的指令行，包括文件包含、宏展开和条件编译。同时，它也处理 _Pragma 这样的操作符。

完成这四个阶段后，生成的翻译单元才进入后续的编译阶段（编译为目标文件）、汇编和链接（与其他目标文件和库链接，最终生成可执行文件或库）3。这个清晰的流程划分，再次凸显了预处理器作为编译前奏的角色。

第 2 节：文件包含与依赖管理

2.1 #include 指令：工作机制与搜索路径语义

#include 指令是 C++ 代码组织的基础。它指示预处理器将指令本身替换为指定文件的全部内容，从而实现代码的模块化和重用。该指令有两种主要形式，其区别在于文件名两侧的分隔符，这直接影响了预处理器的文件搜索策略：

• #include “file”：使用双引号。这种形式通常用于包含项目本地的头文件。预处理器的搜索顺序一般始于包含该指令的源文件所在的目录，如果未找到，再继续搜索由编译器配置指定的系统标准包含路径。
• #include <file>：使用尖括号。这种形式主要用于包含标准库头文件或第三方库头文件。其搜索路径通常仅限于系统标准包含路径，例如通过编译器命令行选项（如 GCC/Clang 的 -I 选项）或环境变量指定的目录。

需要注意的是，确切的搜索顺序是实现定义的（implementation-defined），并且可以通过编译器设置进行高度定制。

2.2 多次包含的挑战：深入解析包含守卫

#include 指令纯粹的“复制-粘贴”机制带来了一个严峻的挑战：如果同一个头文件在一个翻译单元中被直接或间接地包含多次（即“传递性包含”），会导致其中的类、函数或变量被多次定义。这将违反 C++ 的“单一定义规则”（One Definition Rule, ODR），并引发编译错误。

为了解决这个问题，C++ 社区发展出了一种被称为“包含守卫”（include guard）的经典编程范式。这是一种利用条件编译指令（#ifndef, #define, #endif）构建的模式，确保任意头文件的内容在单个翻译单元中只被处理一次。

一个标准的包含守卫示例如下：

#ifndef MY_UNIQUE_HEADER_GUARD_H
#define MY_UNIQUE_HEADER_GUARD_H

// 头文件的所有内容（类定义、函数声明等）
//...

#endif // MY_UNIQUE_HEADER_GUARD_H

当预处理器第一次遇到此头文件时，宏 MY_UNIQUE_HEADER_GUARD_H 尚未定义，因此 #ifndef 条件为真，头文件内容被正常处理，并且该宏被定义。当后续再次包含此头文件时，#ifndef 条件变为假，预处理器会直接跳过从 #ifndef 到 #endif 之间的所有内容，从而避免了重复定义。这种机制并非语言的内置功能，而是开发者为弥补预处理器 #include 模型的内在缺陷而创造出的一种强制性变通方案。这一缺陷是如此根本，以至于它成为了推动 C++20 模块（Modules）诞生的主要动机之一。

2.3 #pragma once：一种务实但非标准的解决方案

#pragma once 是一个被绝大多数现代编译器广泛支持的非标准指令，其功能与包含守卫完全相同。当预处理器在文件中扫描到此指令时，它会记录该文件的唯一标识（通常是其文件系统路径），并在当前翻译单元的后续处理中自动忽略对该文件的所有再次包含请求。

权衡分析：#pragma once vs. 包含守卫

• 优点：
  • 简洁性：比传统的包含守卫更简洁，减少了样板代码。
  • 减少错误：避免了因宏名冲突或拼写错误导致的包含守卫失效问题。
  • 潜在的编译性能提升：编译器可以通过文件路径直接判断是否需要再次打开和解析文件，理论上比处理包含守卫的宏定义更快。
• 缺点：
  • 非标准：其行为并非由 C++ 语言标准保证，尽管实践中已被广泛支持。
  • 依赖文件系统：它依赖于编译器通过文件系统路径来唯一识别文件。在复杂的环境中，如涉及网络挂载、符号链接或大小写不敏感的文件系统，可能会导致识别失败，从而无法有效防止多次包含。
  • 可移植性：传统的包含守卫模式是 100% 可移植的，并且其语义清晰明确，不依赖任何编译器或文件系统的特定行为。

在实践中，许多项目会同时使用这两种技术，以兼顾性能和可移植性。然而，对于追求最高可移植性的库代码，传统的包含守卫仍然是更稳妥的选择。

第 3 节：宏元编程：定义与展开

3.1 类对象宏：符号常量及其风险

类对象宏（Object-like macro）通过 #define NAME value 的形式定义，其作用是在预处理阶段进行直接的令牌替换。在 C 语言的早期，这是定义符号常量的主要方式。然而，在现代 C++ 中，这种做法被强烈反对，其原因深刻且多方面：

• 缺乏类型安全：宏本身没有类型。在 #define PI 3.14 中，PI 只是一个预处理令牌。在替换后，编译器看到的只是字面量 3.14。这完全绕过了 C++ 的类型检查系统，可能导致难以察觉的类型错误。
• 作用域污染：宏不遵守 C++ 的作用域规则（如命名空间、类作用域等）。一个宏一旦被定义，其效力将持续到文件末尾或遇到对应的 #undef 指令。这极易引发命名冲突，尤其是在包含多个第三方库的大型项目中。
• 调试困难：宏名（如 PI）在预处理后便消失了，它不会出现在编译器的符号表中。因此，在调试器中，开发者只能看到替换后的字面量值，这使得代码的意图变得模糊，增加了调试的难度。

现代 C++ 提供了完美的替代方案：const 和 constexpr 变量。它们是语言的原生部分，具有明确的类型、遵守作用域规则，并且对调试器可见，从而解决了类对象宏的所有缺点。

3.2 类函数宏：模拟函数与陷阱揭示

类函数宏（Function-like macro）接受参数，例如 #define SQUARE(x) ((x)*(x))，提供了类似函数调用的接口。然而，其本质仍然是纯粹的文本替换，这使其充满了危险的陷阱。

深入剖析常见陷阱：

• 操作符优先级问题：未使用足够括号是类函数宏最经典的错误来源。如果 SQUARE 定义为 x*x，那么 SQUARE(a+b) 将被错误地展开为 a+b*a+b，其计算结果与预期大相径庭。因此，为每个参数和整个宏体都加上括号是编写类函数宏的铁律。
• 副作用的多次求值：这是类函数宏最危险的缺陷。如果传递给宏的参数带有副作用（如 ++、-- 或函数调用），该副作用可能会被多次触发。例如，SQUARE(i++) 会展开为 ((i++)*(i++))，这会导致 i 被增加两次，并产生未定义行为。
• 缺乏类型安全与命名空间感知：与类对象宏一样，类函数宏也是类型不安全的，并且不遵守命名空间规则，无法实现函数重载。
• 在控制结构中的意外行为：一个包含多条语句的宏，如果没有使用 do {… } while(0) 结构进行包装，在 if-else 语句中使用时可能会破坏代码逻辑。例如，if (condition) MY_MULTI_STATEMENT_MACRO(); else… 可能会因为宏展开后的分号而导致 else 悬空。

对于这些问题，现代 C++ 同样提供了全面且优越的替代方案，包括 inline 函数、函数模板和 Lambda 表达式。这些语言特性提供了类型安全、可预测的求值顺序、正确的作用域行为以及零开销的抽象能力。

3.3 #undef 指令：管理宏的作用域

#undef 指令用于移除一个已定义的宏。它的主要用途有两个：

1. 限制宏的“作用域”：通过在代码块前后使用 #define 和 #undef，可以将一个宏的影响范围限制在特定的代码区域内，防止其污染全局命名空间。
2. 允许宏的重定义：取消一个宏的定义后，可以为其赋予新的定义。这在某些复杂的配置场景或高级宏技巧（如 X-Macros）中非常关键。

3.4 可变参数宏：…、__VA_ARGS__ 与 GNU 扩展

C99 标准引入并被 C++ 采纳的可变参数宏（Variadic Macro），允许宏定义接受数量可变的参数。这通过在参数列表末尾使用省略号 … 来实现。所有与省略号匹配的参数（包括它们之间的逗号）都可以通过预定义的标识符 __VA_ARGS__ 在宏体中访问。

一个常见的应用是创建自定义的日志或断言宏：

#define LOG(format,...) printf(format, __VA_ARGS__)

处理尾随逗号问题：当可变参数部分为空时，__VA_ARGS__ 会展开为空，这可能导致宏展开后出现一个多余的尾随逗号，从而引发编译错误。例如 LOG(“message”) 展开为 printf(“message”, )。针对此问题，存在两种主流解决方案：

• GNU ##__VA_ARGS__ 扩展：这是 GCC 和 Clang 支持的一个流行扩展。在 __VA_ARGS__ 前面放置 ## 操作符，如果 __VA_ARGS__ 为空，预处理器会自动移除 ## 前面的逗号。
• C++20 __VA_OPT__：这是 C++20 标准引入的官方解决方案。__VA_OPT__(content) 的行为是：如果 __VA_ARGS__ 非空，它展开为 content；如果 __VA_ARGS__ 为空，它展开为空。这提供了一种可移植且清晰的方式来处理尾随逗号问题。

宏的历史是一部编程语言设计的演进史。一个早期强大但充满危险的特性，随着语言的发展，被一系列更安全、更集成、语义更清晰的语言原生构造所逐步取代。对于现代 C++ 开发者而言，理解宏不仅仅是掌握其语法，更重要的是理解其危险性，并熟知每一种宏用法的现代替代方案。预处理器已从一个主要的抽象工具，演变为一个仅在别无选择时才使用的最后手段。

第 4 节：预处理器操作符与高级技术

除了基本的宏定义，预处理器还提供了专门的操作符来执行更复杂的文本操作，这催生了一些强大但晦涩的高级编程技术。

4.1 字符串化操作符（#）：将令牌转换为字符串字面量

字符串化（Stringification）操作符 #，当在类函数宏的定义中置于参数名前时，会将调用时传递给该参数的实际令牌序列转换为一个 C++ 字符串字面量。

一个关键的行为特性是，参数在被字符串化之前不会进行宏展开。例如：

#define STRINGIFY(x) #x
#define VERSION 1.2
const char* version_str = STRINGIFY(VERSION); // 结果是 "VERSION"，而不是 "1.2"

预处理器会自动处理参数中的引号和反斜杠，对它们进行转义，以生成一个语法正确的字符串字面量。例如，STRINGIFY(p = “foo\n”😉 会生成 “p = \“foo\\n\”;”。

4.2 令牌粘贴操作符（##）：合并令牌

令牌粘贴（Token-pasting）操作符 ## 用于在宏展开期间将两个相邻的令牌连接成一个单一的新令牌。当其中一个或两个令牌是宏参数时，这个操作符的威力才能完全显现，它允许在编译时动态地构建标识符（如变量名或函数名）。

例如，可以创建一个宏来简化命令分派表的定义：

#define COMMAND(NAME) { #NAME, NAME ## _command }

void quit_command();
void help_command();

struct command commands = {
    COMMAND(quit), // 展开为 { "quit", quit_command }
    COMMAND(help), // 展开为 { "help", help_command }
};

在这个例子中，## 将参数 quit 和后缀 _command 粘贴在一起，形成了新的有效令牌 quit_command。需要注意的是，粘贴的结果必须是一个合法的 C++ 令牌，否则行为是未定义的或将导致编译错误。

4.3 高级范式：用于字符串化宏值的双重展开技巧

结合上述两个操作符，可以实现一个非常重要且广泛使用的预处理器范式：字符串化一个宏展开后的值，而不是宏本身的名字。

问题在于，直接使用 # 操作符会阻止宏展开。为了解决这个问题，需要引入一个中间宏，形成所谓的“双重展开”（double-expansion）技巧 25：

#define STRINGIFY_IMPL(x) #x
#define STRINGIFY(x) STRINGIFY_IMPL(x)

#define VERSION 1.2
const char* version_str = STRINGIFY(VERSION); // 结果是 "1.2"

工作机制详解：

1. 当预处理器遇到 STRINGIFY(VERSION) 时，它首先尝试展开 STRINGIFY。
2. 根据 STRINGIFY 的定义 STRINGIFY_IMPL(x)，其参数 x 并没有被 # 或 ## 直接操作。根据预处理器的规则，此时参数 VERSION 会被正常展开。
3. VERSION 展开为其值 1.2。
4. 现在，预处理器处理的表达式变成了 STRINGIFY_IMPL(1.2)。
5. 接着，预处理器展开 STRINGIFY_IMPL。根据其定义 #x，参数 1.2 被字符串化。
6. 最终结果为字符串字面量 “1.2”。

这个技巧是掌握预处理器宏的关键一步，它揭示了宏展开顺序的微妙之处，并在许多需要将编译时常量转换为字符串的场景中（如版本信息嵌入、断言信息等）发挥着重要作用。

4.4 X-Macros 技术：一种强大的代码生成模式

X-Macros 是一种高级的、惯用的预处理器编程模式，用于从一个单一的数据源生成多组相关联的代码，从而消除冗余、保证数据的一致性。它本质上是在预处理器层面实现的一种“代码生成”技术。

工作机制：

1. 定义数据列表：首先，创建一个宏（或一个单独的 .def / .inc 文件），其中包含一系列对一个占位宏（通常命名为 X）的调用。这个列表本身不生成任何代码。

// file: error_codes.def
X(Success, 0, "Operation successful")
X(NotFound, 1, "Resource not found")
X(PermissionDenied, 2, "Permission denied")

2. 重复展开列表：在需要生成代码的地方，通过临时定义 X 宏来指定每次迭代生成的代码模式，然后包含（或调用）数据列表宏，最后用 #undef 清除 X 的定义。这个过程可以重复多次，每次 X 的定义都不同。

示例应用：

• 生成枚举类型：

typedef enum {
#define X(Name, Code, Desc) EC_##Name = Code,
#include "error_codes.def"
#undef X
} ErrorCode;

• 生成错误码到字符串的转换函数：

const char* ErrorCodeToString(ErrorCode code) {
    switch (code) {
#define X(Name, Code, Desc) case EC_##Name: return Desc;
#include "error_codes.def"
#undef X
    default: return "Unknown error";
    }
}

X-Macros 模式非常强大，它确保了枚举、字符串、甚至分派表等所有相关代码都源自同一个“真理之源”（single source of truth）。任何对错误码列表的增删改都将自动反映到所有生成代码中，极大地提高了代码的可维护性。然而，这种技术的代码可读性较差，对不熟悉的开发者来说可能非常晦涩。现代的一些变体通过将“工作宏”作为参数传递给列表宏来改善可读性。这些高级技巧代表了预处理器元编程的巅峰，但同时也清晰地表明，开发者正在试图弥补核心语言在编译时代码生成和反射能力上的缺失。

第 5 节：条件编译：构建代码的可变性

条件编译是预处理器最重要且至今仍无法被现代 C++ 特性完全替代的功能之一。它允许开发者根据编译时的条件，选择性地包含或排除代码块，是构建跨平台、多配置软件的基石。

5.1 #if/#elif/#else/#endif 结构与 defined() 操作符

这组指令构成了条件编译的核心框架。#if 指令后跟一个常量整数表达式，如果表达式的计算结果为非零，则其后的代码块被保留；否则，代码块被预处理器丢弃。

#elif（else if）和 #else 提供了多分支和默认分支的逻辑，最后的 #endif 标志着条件编译块的结束。

在 #if 表达式中，defined() 操作符至关重要。defined(MACRO) 或 defined MACRO 会在 MACRO 已被定义时求值为 1，否则求值为。这是在 #if 语句中检查宏是否存在的首选方式，因为它允许与其他条件通过逻辑与（&&）和逻辑或（||）进行组合，构建复杂的编译条件。

5.2 语法快捷方式：#ifdef 与 #ifndef

为了简化最常见的“检查宏是否存在”的场景，预处理器提供了两个语法糖：

• #ifdef MACRO：完全等价于 #if defined(MACRO)。
• #ifndef MACRO：完全等价于 #if!defined(MACRO)。

虽然这些快捷方式很方便，尤其 #ifndef 是实现包含守卫的基础，但在编写复杂的条件逻辑时，使用 #if 配合 defined() 操作符通常能让代码意图更加清晰。

5.3 核心应用场景

条件编译的用途广泛，以下是几个最核心和最正当的应用场景：

• 平台特定代码：这是条件编译最普遍的用途。通过检查编译器预定义的宏（如 _WIN32、__linux__、__APPLE__），可以为不同的操作系统、硬件架构或编译器编写特定的实现代码。
• 构建配置管理：根据构建类型（如 Debug vs. Release）来启用或禁用某些功能。一个典型的例子是使用 NDEBUG 宏，当它被定义时（通常在 Release 构建中），assert 宏会变为空操作，从而移除断言检查的开销。
• API 版本控制：当代码需要兼容一个库的多个版本时，可以使用条件编译来选择性地调用不同版本的 API 或提供兼容性垫片（shim）。
• 包含守卫：如第 2 节所述，#ifndef 是实现这一基本模式的关键。
• 功能开关：通过在构建系统中定义宏（例如，使用编译器的 -D 或 /D 选项），可以方便地开启或关闭实验性功能、日志记录或其他可选的代码模块。

条件编译是预处理器少数几个在现代 C++ 中依然保持其核心地位的功能领域。虽然像 if constexpr 这样的新特性可以在编译时根据类型信息选择代码路径，但它们是在 C++ 语言内部运作的。它们无法根据外部的构建环境（如目标平台或用户指定的编译选项）来条件性地包含头文件或改变代码结构。预处理器在编译的最前端运行，能够根据这些外部信息从根本上重塑将要被编译的令牌流。因此，这里存在一个清晰的职责划分：对于基于 C++ 语言内部类型和值的编译时决策，应优先使用 if constexpr；而对于基于外部构建环境和平台的编译时决策，预处理器的 #if/#ifdef 仍然是正确且必要的工具。

第 6 节：诊断、控制与实现定义指令

除了代码转换，预处理器还提供了一系列指令，用于在编译时进行诊断、控制编译流程，以及与编译器进行特定于实现的交互。

6.1 编译时消息传递：#error 与 #warning

• #error message：此指令会立即终止编译过程，并向用户显示指定的错误消息。它是一个强大的编译时断言工具，可用于确保满足某些编译前提条件，例如，检查某个必需的宏是否已定义，或者防止代码在不受支持的平台上被编译。

#if!defined(REQUIRED_CONFIG_MACRO)
#error "Compilation requires REQUIRED_CONFIG_MACRO to be defined."
#endif

这个指令通常用在 #if-#elif-#else 结构的 #else 部分，作为一种安全检查，防止代码在不期望的条件下被编译。

• #warning message：此指令会生成一条编译器警告，并显示指定的消息，但编译过程会继续进行。它对于提醒开发者注意潜在问题、弃用的功能或非最优配置非常有用。
  #warning 直到 C++23 才被正式标准化，但在此之前已被主流编译器作为扩展广泛支持。

6.2 源代码映射：#line 指令

#line 指令允许开发者修改编译器内部记录的当前行号和（可选的）文件名。这些信息主要用于编译器在生成错误和警告消息时定位问题代码。

它的主要应用场景是代码生成器，例如解析器生成器（如 Yacc/Bison）或领域特定语言（DSL）的转换器。这些工具会读取一种源文件（如 .y 语法文件）并生成 C++ 源代码（.cpp 文件）。通过在生成的 .cpp 文件中嵌入 #line 指令，它们可以告诉编译器将代码映射回原始的源文件。这样，如果生成的代码中出现编译错误，编译器报告的错误位置将是开发者熟悉的原始文件名和行号，而不是机器生成的、难以理解的中间代码，极大地提升了调试效率。

6.3 #pragma：通往编译器特定行为的网关

#pragma 是 C++ 标准中定义的、用于向编译器提供实现定义（implementation-defined）信息的正式机制。它的核心设计原则是，如果一个编译器无法识别某个 pragma，它必须忽略该指令而不是报错，这保证了使用了特定 pragma 的代码在其他编译器上仍能编译（尽管可能没有预期的效果）43。

#pragma 指令的功能五花八门，完全由编译器厂商决定。以下是一些在主流编译器（MSVC, GCC, Clang）中常见且实用的 pragma：

Pragma	MSVC 支持	GCC 支持	Clang 支持	描述
once	✔	✔	✔	防止头文件被多次包含，作为包含守卫的替代方案。
pack	✔	✔	✔	控制结构体或类的成员对齐方式。对确保二进制兼容性至关重要，但会损害可移植性。
warning	✔	(见下)	(见下)	在 MSVC 中，用于禁用、启用或修改特定警告等级，如 #pragma warning(disable: 4996)。
GCC diagnostic	✖	✔	✔	在 GCC/Clang 中，用于控制诊断信息，功能类似 MSVC 的 warning pragma，如 #pragma GCC diagnostic ignored “-Wunused-variable”。
message	✔	(见下)	(见下)	在 MSVC 中，用于在编译时输出自定义消息，如 #pragma message(“Compiling feature X”)。
GCC warning/error	✖	✔	✔	在 GCC/Clang 中，用于在编译时输出警告或错误，可通过 _Pragma 在宏中使用。
comment(lib,…)	✔	✖	✖	MSVC 专用，在目标文件中嵌入一条记录，指示链接器链接指定的库，如 #pragma comment(lib, “user32.lib”)。
region/endregion	✔	✖	✖	MSVC 专用，在 IDE 中创建可折叠的代码区域，以提高代码的可读性。
GCC poison	✖	✔	✔	GCC/Clang 专用，将一个标识符标记为“有毒”，任何后续对该标识符的使用都会导致硬编译错误。

6.4 _Pragma 操作符：在宏定义中启用 Pragma

#pragma 的一个主要限制是它是一个指令，不能由宏展开生成。为了解决这个问题，C99 标准引入了

_Pragma 操作符，并被 C++11 采纳。

_Pragma(“string-literal”) 的效果与 #pragma string-literal 完全相同，但由于它是一个操作符（类似于 sizeof），因此可以被用在宏定义中。这使得创建能够动态应用 pragma 的复杂宏成为可能。例如，可以创建一个宏来临时禁用某个特定的警告：

#define IGNORE_WARNING_PUSH _Pragma("GCC diagnostic push")
#define IGNORE_WARNING(warning_name) _Pragma(#warning_name)
#define IGNORE_WARNING_POP _Pragma("GCC diagnostic pop")

// 用法
IGNORE_WARNING_PUSH
IGNORE_WARNING("GCC diagnostic ignored \"-Wunused-variable\"")
int x; // 不会产生未使用变量的警告
IGNORE_WARNING_POP

#pragma 体系及其 _Pragma 对应物，是 C++ 生态中一个“必要的恶”。它们是标准委员会的正式承认：标准无法也不应规定所有细节，必须为编译器厂商的创新和平台特定的优化保留一个受控的“后门”。然而，过度依赖 pragma 会将代码库锁定在特定的编译器上，给未来的迁移带来巨大挑战。因此，明智的做法是尽可能地隔离 pragma 的使用，通常将它们包装在平台检查的 #ifdef 块中。

第 7 节：标准预定义宏：一个编译时内省工具包

C++ 标准规定了一些预定义的宏，它们在预处理阶段会被展开为特定的值，为程序提供关于其编译环境的“内省”能力。

7.1 诊断宏

这些宏对于日志记录、调试和断言的实现至关重要，它们可以在运行时或编译时提供代码位置的上下文信息。

• __FILE__：展开为一个字符串字面量，内容是当前源文件的名称。
• __LINE__：展开为一个整型常量，表示当前代码在源文件中的行号。
• __DATE__：展开为一个字符串字面量，表示源文件的编译日期，格式通常为 “Mmm dd yyyy”。
• __TIME__：展开为一个字符串字面量，表示源文件的编译时间，格式通常为 “hh:mm:ss”。

一个典型的应用是自定义断言宏：

#define MY_ASSERT(condition) \
    if (!(condition)) { \
        fprintf(stderr, "Assertion failed: %s, file %s, line %d\n", \
                #condition, __FILE__, __LINE__); \
        abort(); \
    }

7.2 __cplusplus 宏：标准版本的哨兵

__cplusplus 宏展开为一个整型字面量，其值用于标识编译器当前遵循的 C++ 标准版本。这对于编写需要根据不同标准版本启用或禁用特性的可移植代码至关重要。

__cplusplus 宏值与 C++ 标准版本对应表

C++ 标准	发布年份	__cplusplus 值
C++98	1998	199711L
C++11	2011	201103L
C++14	2014	201402L
C++17	2017	201703L
C++20	2020	202002L

数据来源：51

通过检查这个宏的值，代码可以有条件地使用新特性：

#if __cplusplus >= 201703L
#include <optional>
// 使用 std::optional 的代码
#else
// 为旧标准提供替代实现或禁用相关功能
#endif

7.3 编译器特定的注意事项：MSVC 的 __cplusplus 问题

__cplusplus 宏的设计初衷是提供一个简单、可移植的标准版本检测工具。然而，在实际应用中，一个主要的编译器——Microsoft Visual C++ (MSVC)——的行为给这个理想化的模型带来了挑战。

出于对大量现有旧代码的向后兼容性考虑，MSVC 默认情况下总是将 __cplusplus 宏定义为 199711L，无论实际使用的 C++ 标准是什么（例如，即使在使用 C++17 或 C++20 模式编译）53。许多遗留代码库依赖于这个宏的旧值来工作。

为了让 MSVC 报告正确的、与当前标准匹配的 __cplusplus 值，开发者必须在编译选项中显式添加 /Zc:__cplusplus 标志。

这个默认行为是跨平台 C++ 开发中的一个重大“陷阱”。一段依赖 #if __cplusplus >= 201703L 来启用 C++17 特性的代码，在 MSVC 上可能会编译失败，不是因为编译器不支持该特性，而是因为预处理器检查错误地返回了 false。这迫使构建系统（如 CMake）和可移植库的开发者必须专门处理这个 MSVC 特有的情况，从而削弱了 __cplusplus 作为通用标准检查工具的价值。这也深刻地揭示了，即使是“标准”特性，其实际行为也可能受到实现厂商历史包袱的影响。对于需要精确检测标准版本的 MSVC 代码，更可靠的方式是检查 _MSVC_LANG 宏，它总能报告正确的标准版本值，不受 /Zc:__cplusplus 选项的影响。

第 8 节：反对预处理器的理由：现代 C++ 替代方案

随着 C++ 语言的不断演进，其自身提供了越来越多类型安全、语义清晰且功能强大的特性，这些特性在绝大多数场景下都优于传统的预处理器宏。本节将系统性地论证为何应在现代 C++ 开发中最大限度地避免使用预处理器，并提供一份详尽的替代方案指南。

8.1 宏缺陷的批判性分析

预处理器的核心问题在于其纯文本替换的本质，这导致了一系列根深蒂固的缺陷，包括但不限于：

• 缺乏类型安全：宏不参与类型检查，可能导致意外的类型转换和错误。
• 无视作用域：宏定义是全局性的，容易污染命名空间并引发难以追踪的命名冲突。
• 调试困难：宏名在预处理后消失，使调试器无法提供有用的信息。
• 意外的副作用：类函数宏可能多次求值其参数，导致未定义行为和逻辑错误。
• 语法脆弱性：宏的编写需要非常小心，否则容易因操作符优先级或在控制结构中的使用不当而引入错误。

C++ 的演进过程，在很大程度上可以看作是一场旨在提供语言原生、语义感知的特性，以系统性地淘汰预处理器这些基于文本技巧的“战役”。

8.2 预处理器构造的替代方案：一份对比指南

下表详细对比了常见的预处理器用法及其对应的现代 C++ 替代方案，旨在为代码现代化提供一份实用的操作手册。

用途	预处理器方法	现代 C++ 替代方案	分析（类型安全、作用域、调试性、可读性）
符号常量	#define PI 3.14	constexpr double PI = 3.14;	constexpr 提供了类型安全，遵守作用域规则，对调试器可见，且能保证编译时求值。完胜宏定义。
简单函数	#define MAX(a,b) ((a)>(b)?(a):(b))	inline int max(…) 或 template<typename T> const T& max(const T& a, const T& b)	inline 函数和函数模板是真正的函数，具有类型检查、参数求值一次的保证，并且可以重载和在命名空间中使用。
类型泛型代码	#define SWAP(t,a,b) { t tmp=a; a=b; b=tmp; }	template<typename T> void swap(T& a, T& b)	模板是 C++ 实现泛型编程的正确方式，提供完全的类型安全和编译时代码生成，远比宏强大和安全。
条件编译（基于类型）	#if 配合 sizeof 或类型宏	if constexpr (std::is_integral_v<T>) {… } (C++17)	if constexpr 在编译时根据类型特性选择性地编译代码分支，被丢弃的分支甚至不需要是合法的。它在语言层面实现了类型驱动的条件编译，比宏更安全、更直观。
可变参数操作	LOG(format,…)	template<typename… Args> void log(const char* format, Args&&… args)	可变参数模板提供了类型安全的方式来处理任意数量和类型的参数，支持完美转发，并且是 C++ 语言的一等公民。
编译时错误	#if!CONDITION#error “Message”#endif	static_assert(CONDITION, “Message”);	static_assert 允许在编译时对常量表达式进行断言，其语法更简洁，意图更明确，并且与 C++ 的 constexpr 体系完美集成。
源代码位置	__FILE__, __LINE__	std::source_location (C++20)	std::source_location 将源文件、行号、列号和函数名封装在一个对象中，可以作为函数参数传递，提供了比宏更结构化、更灵活的方式来获取代码位置信息。

对于现代 C++ 开发者而言，使用预处理器的“最佳实践”就是尽可能不使用它，除非不存在任何语言原生的替代方案。专家的职责已经从掌握晦涩的预处理器技巧，转变为精通那些让这些技巧变得多余的现代 C++ 语言特性。

第 9 节：未来展望：C++20 模块与预处理器角色的式微

长久以来，C++ 的编译模型都受困于一个根本性的缺陷——基于文本包含的头文件系统。C++20 引入的模块（Modules）功能，正是为了从根本上解决这一问题，它不仅是一次性能优化，更是一场将改变 C++ 代码组织方式和编译生态的范式革命。

9.1 文本包含模型的内在缺陷

第 2 节中讨论的 #include 机制的问题，实际上是整个系统性问题的表征。基于文本的包含模型存在两大核心缺陷：

1. 编译效率低下：预处理器在处理每个翻译单元时，都会独立地、重复地打开、读取并解析相同的头文件（如 <iostream>, <vector> 等）。在一个大型项目中，这会导致成千上万次的重复工作，极大地浪费了编译时间。
2. 缺乏封装性与脆弱性：#include 的文本替换特性意味着头文件之间没有隔离。一个头文件中定义的宏可以“泄漏”出去，意外地影响另一个包含了它的头文件或源文件。这导致了所谓的“包含顺序依赖”问题，即更改头文件的包含顺序可能会导致编译成功或失败，使得代码库非常脆弱。

9.2 C++20 模块简介

模块是 C++20 引入的一项重大语言特性，旨在替代传统的头文件系统。其核心思想是：

• 一次编译，多次使用：一个模块（由模块接口单元定义）只需被编译器处理一次，其导出的公开接口信息被编译成一种高效的二进制格式，称为“二进制模块接口”（Binary Module Interface, BMI）文件。
• 高效导入：当其他代码单元通过 import 关键字导入该模块时，编译器直接读取预先编译好的 BMI 文件，而不是重新解析成千上万行的文本头文件。这个过程比处理文本头文件快几个数量级。
• 真正的封装：模块提供了真正的逻辑封装，开发者可以精确控制哪些声明被导出（export），哪些仅在模块内部可见。

9.3 模块如何隔离宏状态

对于本报告而言，模块最关键的影响在于它从根本上隔离了预处理器状态。在一个模块单元内部声明的宏、预处理指令以及未导出的名称，对于导入该模块的翻译单元是完全不可见的。

这意味着：

• 宏泄漏问题被彻底解决：在一个模块实现中定义的内部宏，绝不会影响到导入该模块的用户代码。
• 包含顺序依赖不复存在：以不同顺序 import 模块不会产生任何差异，因为它们之间没有预处理器状态的交互。
• 包含守卫成为历史：由于模块只会被编译器处理一次，传统的 #ifndef/#define 包含守卫对于模块而言变得毫无必要。

9.4 长期趋势：一个不再严重依赖预处理的 C++ 世界

尽管模块的生态系统（编译器支持、构建系统集成、第三方库迁移）仍在发展成熟中 58，但它无疑代表了 C++ 未来的发展方向。模块的普及将极大地削弱预处理器的作用。

在未来，预处理器的角色将被进一步压缩，主要集中在以下几个无法被替代的领域：

• 通过“全局模块分片”（global module fragment）处理无法模块化的遗留头文件。
• 实现与构建系统交互的平台和配置相关的条件编译。

模块的出现，是 C++ 语言为驯服预处理器所迈出的最后，也是最关键的一步。此前的语言特性（如 constexpr, template）提供了对宏具体用法的替代方案，而模块则提供了对整个文本包含机制的替代方案——正是这个机制，构成了预处理器影响力的基石。模块的广泛采用，将比历史上任何其他特性更能有效地降低预处理器的重要性和危险性。

第 10 节：结论：以现代视角审视一个遗留工具

10.1 预处理器的演进之旅

本报告全面剖析了 C++ 预处理器，追溯了它从 C 语言中一个不可或缺的基础工具，演变为 C++ 中一个功能强大但问题丛生的遗留特性，并最终在现代 C++ 时代被重新定位为一个高度专业化的工具的完整历程。

最初，预处理器以其直接的文本操作能力，为 C/C++ 提供了代码组织、常量定义和零开销抽象的基本手段。然而，随着 C++ 语言自身的发展，其对类型安全、作用域和封装的日益重视，使得预处理器的非语义、全局性操作模式显得格格不入，并成为大量难以调试的错误的根源。

C++ 标准的每一次迭代，都可以看作是对预处理器功能的一次“收复”。从 const 到 constexpr，从 inline 函数到模板，再到 C++17 的 if constexpr 和 C++20 的 std::source_location，语言本身逐步提供了更安全、更强大、更符合 C++ 编程范式的原生替代方案。最终，C++20 模块的出现，更是对预处理器赖以生存的文本包含模型发起了根本性的挑战，预示着一个宏泄漏和头文件混乱时代的大幕即将落下。

10.2 审慎使用的战略性建议

对于现代 C++ 开发者，与预处理器打交道的指导原则应是审慎和克制。以下是一组可操作的战略性建议：

1. 优先使用语言特性：对于常量、函数、类型泛型编程、类型驱动的条件逻辑以及编译时断言，应始终优先选择 C++ 语言提供的原生特性（constexpr, inline, template, if constexpr, static_assert 等）。
2. 明确预处理器的核心领域：将预处理器的使用严格限制在其不可替代的核心领域：与外部构建环境（平台、架构、编译器、构建配置）交互的条件编译。
3. 坚持使用包含保护：在所有非模块化的头文件中，必须始终如一地使用包含守卫（#ifndef/#define/#endif）或 #pragma once 来防止多次包含。
4. 隔离并最小化宏定义：尽可能避免在头文件中定义宏。如果必须这样做，请使用长而独特的、带有项目前缀的宏名以避免冲突，并考虑在使用后立即 #undef 它。
5. 拥抱 C++20 模块：在新项目中，应积极采用 C++20 模块。这不仅能显著提升编译速度，还能从根本上解决宏带来的封装性问题。

10.3 未来展望

展望未来，C++ 语言的发展趋势将继续削弱预处理器的作用。诸如静态反射（Static Reflection）等正在讨论中的未来特性，有望提供一种类型安全的方式来在编译时检查和操作代码结构，这可能会最终取代像 X-Macros 这样高级但晦涩的预处理器技巧。

届时，C++ 预处理器将彻底回归其最初的、也是最合适的角色：一个连接源代码与编译环境的桥梁，一个处理平台差异的工具，而不是一个用于程序内元编程和抽象的语言扩展。掌握它的历史和局限性，并熟练运用其现代替代方案，是每一位专业 C++ 工程师的必修课。

引用的著作

1. C preprocessor - Wikipedia, 访问时间为 九月 23, 2025， https://en.wikipedia.org/wiki/C_preprocessor
2. C++ Preprocessor And Preprocessor Directives - GeeksforGeeks, 访问时间为 九月 23, 2025， https://www.geeksforgeeks.org/cpp/cpp-preprocessors-and-directives/
3. How does the compilation/linking process work? - c++ - Stack Overflow, 访问时间为 九月 23, 2025， https://stackoverflow.com/questions/6264249/how-does-the-compilation-linking-process-work
4. What is the difference between a macro and a const in C++? - Stack Overflow, 访问时间为 九月 23, 2025， https://stackoverflow.com/questions/6393776/what-is-the-difference-between-a-macro-and-a-const-in-c
5. en.wikipedia.org, 访问时间为 九月 23, 2025， https://en.wikipedia.org/wiki/C_preprocessor#:~:text=defined-,History,string%20replacement%20macros%20via%20%23define%20.
6. Getting Started | C++ Fundamentals - Packt Subscription, 访问时间为 九月 23, 2025， https://subscription.packtpub.com/book/programming/9781789801491/1/ch01lvl1sec03/the-c-compilation-model
7. 3.7. Defining the Include File Directory Search Path — C29 Clang Compiler Tools User’s Guide - Texas Instruments, 访问时间为 九月 23, 2025， https://software-dl.ti.com/codegen/docs/c29clang/compiler_tools_user_guide/migration_guide/mapping_ticl_options_to_ticlang/defining_include_file_search_path.html
8. Search sequences for include files - IBM, 访问时间为 九月 23, 2025， https://www.ibm.com/docs/en/zos/2.4.0?topic=compiling-search-sequences-include-files
9. Pragmas (The C Preprocessor) - GCC, the GNU Compiler Collection, 访问时间为 九月 23, 2025， https://gcc.gnu.org/onlinedocs/cpp/Pragmas.html
10. What code have you written with #pragma you found useful? [closed] - Stack Overflow, 访问时间为 九月 23, 2025， https://stackoverflow.com/questions/2703528/what-code-have-you-written-with-pragma-you-found-useful
11. What is the purpose of the _Pragma directive? - Quora, 访问时间为 九月 23, 2025， https://www.quora.com/What-is-the-purpose-of-the-Pragma-directive
12. When will the C, C++ standards formally recognize #pragma once? - Reddit, 访问时间为 九月 23, 2025， https://www.reddit.com/r/cpp_questions/comments/jy3zsh/when_will_the_c_c_standards_formally_recognize/
13. www.quora.com, 访问时间为 九月 23, 2025， https://www.quora.com/What-is-the-difference-between-using-a-pragma-once-and-an-include-guard-in-C-C-headers#:~:text=Programming%20in%20C-,What%20is%20the%20difference%20between%20using%20a%20pragma%20once%20and,guard%20in%20C%2FC%2B%2B%20headers%3F&text=The%20difference%20is%20that%20the,already%20scanned%20%E2%80%9Cthis%E2%80%9D%20file.
14. Implementation defined behavior control - cppreference.com - C++ Reference, 访问时间为 九月 23, 2025， https://en.cppreference.com/w/cpp/preprocessor/impl
15. medium.com, 访问时间为 九月 23, 2025， https://medium.com/@newcreation2kal/const-constexpr-and-macros-in-c-db806ece0b87#:~:text=In%20modern%20C%2B%2B%20(C,better%20type%20safety%20and%20readability.
16. Replacing the Preprocessor in Modern C++, 访问时间为 九月 23, 2025， https://learnmoderncpp.com/2023/12/29/replacing-the-preprocessor-in-modern-c/
17. Macro Evil in C++ Code, 访问时间为 九月 23, 2025， https://arne-mertz.de/2019/03/macro-evil/
18. Inline functions vs Preprocessor macros - c++ - Stack Overflow, 访问时间为 九月 23, 2025， https://stackoverflow.com/questions/1137575/inline-functions-vs-preprocessor-macros
19. C/C++ Unknown Concept “Good and Bad Macros” | by Chetan J - Medium, 访问时间为 九月 23, 2025， https://medium.com/@Chetan_J/c-c-unknown-concept-good-and-bad-macros-e925e8f1b37f
20. www.geeksforgeeks.org, 访问时间为 九月 23, 2025， https://www.geeksforgeeks.org/cpp/difference-between-inline-and-macro-in-c/#:~:text=In%20C%2B%2B%2C%20inline%20may,automatically%20made%20the%20inline%20functions.
21. The #undef directive - IBM, 访问时间为 九月 23, 2025， https://www.ibm.com/docs/en/zos/2.4.0?topic=directives-undef-directive
22. Undefining and Redefining Macros (The C Preprocessor), 访问时间为 九月 23, 2025， https://gcc.gnu.org/onlinedocs/cpp/Undefining-and-Redefining-Macros.html
23. Variadic macros - Microsoft Learn, 访问时间为 九月 23, 2025， https://learn.microsoft.com/en-us/cpp/preprocessor/variadic-macros?view=msvc-170
24. Variadic Macros (The C Preprocessor) - GNU, 访问时间为 九月 23, 2025， https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html
25. Stringification - The C Preprocessor - GCC, the GNU Compiler Collection, 访问时间为 九月 23, 2025， https://gcc.gnu.org/onlinedocs/gcc-4.8.5/cpp/Stringification.html
26. Stringizing (The C Preprocessor) - GCC, the GNU Compiler Collection, 访问时间为 九月 23, 2025， https://gcc.gnu.org/onlinedocs/cpp/Stringizing.html
27. The C Preprocessor: Concatenation, 访问时间为 九月 23, 2025， https://gcc.gnu.org/onlinedocs/gcc-7.5.0/cpp/Concatenation.html
28. Token Pasting Operator in c, you should know - Aticleworld, 访问时间为 九月 23, 2025， https://aticleworld.com/token-pasting-operator/
29. The STRINGIFY C preprocessor macro - Precheur.org, 访问时间为 九月 23, 2025， https://henry.precheur.org/code/STRINGIFY/
30. Stringification of a macro value - Stack Overflow, 访问时间为 九月 23, 2025， https://stackoverflow.com/questions/2653214/stringification-of-a-macro-value
31. X macro - Wikipedia, 访问时间为 九月 23, 2025， https://en.wikipedia.org/wiki/X_macro
32. What are X-macros? – Arthur O’Dwyer - GitHub Pages, 访问时间为 九月 23, 2025， https://quuxplusone.github.io/blog/2021/02/01/x-macros/
33. X-Macros in C - GeeksforGeeks, 访问时间为 九月 23, 2025， https://www.geeksforgeeks.org/c/x-macros-in-c/
34. Learning X Macros in C - YouTube, 访问时间为 九月 23, 2025， https://www.youtube.com/watch?v=01kxtRGDcNA
35. My Favorite C++ Pattern: X Macros (2023) - Hacker News, 访问时间为 九月 23, 2025， https://news.ycombinator.com/item?id=43472143
36. Conditional compilation directives - IBM, 访问时间为 九月 23, 2025， https://www.ibm.com/docs/en/zos/2.4.0?topic=directives-conditional-compilation
37. #ifdef and #ifndef directives (C/C++) | Microsoft Learn, 访问时间为 九月 23, 2025， https://learn.microsoft.com/en-us/cpp/preprocessor/hash-ifdef-and-hash-ifndef-directives-c-cpp?view=msvc-170
38. The #error directive - IBM, 访问时间为 九月 23, 2025， https://www.ibm.com/docs/en/zos/2.4.0?topic=directives-error-directive
39. Conditional compile-time warning in C++ - Stack Overflow, 访问时间为 九月 23, 2025， https://stackoverflow.com/questions/77549920/conditional-compile-time-warning-in-c
40. #line directive (C/C++) | Microsoft Learn, 访问时间为 九月 23, 2025， https://learn.microsoft.com/en-us/cpp/preprocessor/hash-line-directive-c-cpp?view=msvc-170
41. The #line directive - IBM, 访问时间为 九月 23, 2025， https://www.ibm.com/docs/en/zos/2.4.0?topic=directives-line-directive
42. support.hpe.com, 访问时间为 九月 23, 2025， https://support.hpe.com/hpesc/public/docDisplay?docId=a00113893en_us&page=pragma_Directives.html&docLocale=en_US#:~:text=%23pragma%20directives%20are%20used%20within,certain%20kinds%20of%20special%20processing.&text=The%20_CRI%20specification%20is%20optional,that%20it%20does%20not%20recognize.
43. Learn #pragma Pragma Directive In C++ - Learn C++, 访问时间为 九月 23, 2025， https://learncplusplus.org/learn-pragma-pragma-directive-in-c/
44. C++ Compiler Secrets: Pragma - C++ Senioreas - WordPress.com, 访问时间为 九月 23, 2025， https://cppsenioreas.wordpress.com/2020/11/29/cpp-compiler-secrets-pragma/
45. The C Preprocessor: Pragmas - GCC, the GNU Compiler Collection, 访问时间为 九月 23, 2025， https://gcc.gnu.org/onlinedocs/gcc-7.5.0/cpp/Pragmas.html
46. The _Pragma preprocessing operator - IBM, 访问时间为 九月 23, 2025， https://www.ibm.com/docs/ssw_ibm_i_74/rzarg/pragma_operator.htm
47. The _Pragma preprocessing operator - IBM, 访问时间为 九月 23, 2025， https://www.ibm.com/docs/SSLTBW_2.4.0/com.ibm.zos.v2r4.cbclx01/pragma_operator.htm
48. 5.12 The _Pragma Operator, 访问时间为 九月 23, 2025， http://downloads.ti.com/docs/esd/SPNU151V/the–pragma-operator-slau1329622.html
49. Difference between #pragma and _Pragma() in C - Stack Overflow, 访问时间为 九月 23, 2025， https://stackoverflow.com/questions/45477355/difference-between-pragma-and-pragma-in-c
50. Standard predefined macro names - IBM, 访问时间为 九月 23, 2025， https://www.ibm.com/docs/en/zos/2.4.0?topic=directives-standard-predefined-macro-names
51. Predefined Macros in C with Examples - GeeksforGeeks, 访问时间为 九月 23, 2025， https://www.geeksforgeeks.org/c/predefined-macros-in-c-with-examples/
52. Is there a standard definition for __cpl - C++ Forum, 访问时间为 九月 23, 2025， https://cplusplus.com/forum/general/278758/
53. /Zc:__cplusplus (Enable updated __cplusplus macro) | Microsoft Learn, 访问时间为 九月 23, 2025， https://learn.microsoft.com/en-us/cpp/build/reference/zc-cplusplus?view=msvc-170
54. Cannot set __cplusplus to C++17 standard with Visual Studio and CMake - Stack Overflow, 访问时间为 九月 23, 2025， https://stackoverflow.com/questions/57102212/cannot-set-cplusplus-to-c17-standard-with-visual-studio-and-cmake
55. if constexpr in C++ 17 - GeeksforGeeks, 访问时间为 九月 23, 2025， https://www.geeksforgeeks.org/cpp/if-constexpr-in-cpp-17/
56. C++20: The Advantages of Modules – MC++ BLOG - Modernes C++, 访问时间为 九月 23, 2025， https://www.modernescpp.com/index.php/cpp20-modules/
57. Overview of modules in C++ - Microsoft Learn, 访问时间为 九月 23, 2025， https://learn.microsoft.com/en-us/cpp/cpp/modules-cpp?view=msvc-170
58. C++20 Modules: Practical Insights, Status and TODOs | Hacker News, 访问时间为 九月 23, 2025， https://news.ycombinator.com/item?id=45167303
59. What to do with C++ modules? - Hacker News, 访问时间为 九月 23, 2025， https://news.ycombinator.com/item?id=45086210
60. Modules (since C++20) - cppreference.com, 访问时间为 九月 23, 2025， https://en.cppreference.com/w/cpp/language/modules.html