C++20 模块的哪个特性消除了跨翻译单元边界的宏泄漏？

问题的答案。

问题的历史

在 C++20 之前，C++ 的编译模型依赖于通过预处理指令的文本包含。当一个头文件被包含时，预处理器字面上将该头文件的文本复制到包含文件中。这种机制导致在头文件中定义的宏泄漏到每个包含它们的翻译单元的全局命名空间中，从而导致难以诊断的微妙错误和名称冲突。

问题

宏泄漏在大型代码库中造成了维护噩梦。第三方库中定义的宏可能会在消费者代码中静默地重定义关键字或常见标识符，导致编译失败或运行时错误，这些错误看起来与实际原因无关。传统的解决方法，如 #undef 保护是手动的，容易出错，并且在复杂的依赖图中无法扩展。根本问题是预处理器没有范围或接口边界的概念。

解决方法

C++20 模块引入了一种语义导入机制，这种机制在语言层级上运作，而不是预处理器层级。当导入一个模块时，通过 import module_name;，编译器处理模块的导出接口，而不执行来自导入翻译单元的预处理指令。在模块内定义的宏在未显式导出的情况下保持该模块实现的私有性。这个特性确保宏不跨翻译单元边界泄漏，提供了真正的封装，并防止名称污染。

// mathlib.cpp (模块实现)
module;
#define INTERNAL_CALC_FACTOR 3.14  // 私有宏，不泄漏

export module mathlib;

export double compute(double x) {
    return x * INTERNAL_CALC_FACTOR;
}

// main.cpp (消费者)
import mathlib;

// INTERNAL_CALC_FACTOR 在这里不可见
// #ifdef INTERNAL_CALC_FACTOR 将为 false

int main() {
    double result = compute(10.0);  // 工作正常
}

生活中的情况

一家金融交易公司维护着一个大型代码库，其中包含数百万行代码和数百个模块。他们依赖一个遗留的数学库，该库在其公共头文件中定义了像 MIN 和 MAX 这样的宏。这些宏经常与标准库函数和使用 min 和 max 作为变量名或函数模板的第三方 JSON 解析库发生冲突。

考虑的第一个方法是用 #pragma once 风格的保护将所有第三方头文件包装起来，并在每次包含之后手动 #undef 有问题的宏。这要求开发人员记住哪些头文件定义了哪些宏，并在每次包含后进行清理。这个方法很脆弱，因为漏掉一个 #undef 可能会导致代码库中无关部分的失败。由于预处理器在多个翻译单元中重复处理相同的头文件文本，也显著增加了编译时间。

考虑的第二个方法是将数学库转换为使用内联函数和模板，而不是宏。虽然这解决了泄漏问题，但它需要对遗留库进行广泛修改。数学库被多个团队使用，改变它会有风险，可能破坏依赖于特定宏求值语义或副作用的现有计算。重构工作预计需要六个月，并被认为对交易平台风险太大。

选择的解决方案是迁移到 C++20 模块。团队将数学库转换为一个模块，导出数学函数，同时将宏保持在模块实现内部。通过使用 import mathlib; 而不是 #include <mathlib.h>，消费的翻译单元不再看到 MIN 和 MAX 宏。这个方法对库实现的变更很小——只需添加导出声明和将头文件转换为模块接口单元。迁移花了两周时间，而不是六个月。结果是消除了代码库中的与宏相关的名称冲突，并由于模块的编译接口，编译时间减少了 15%。

候选人常常忽视的要点

模块接口单元的编译二进制格式如何防止宏泄漏，与文本头文件包含相比？

候选人常常忽略 C++20 模块生成的编译模块接口单元 (CMI)，这些是模块导出接口的二进制表示。与通过预处理器处理并包含宏定义为文本的文本头文件不同，CMIs 存储有关导出函数、类型和模板的语义信息。预处理器不处理导入模块的内容；它只看到导入声明。因此，在模块实现中或其接口单元中定义的宏对于导入者是不可见的。这与 #include 根本不同，它字面上复制包括 #define 指令的文本。理解这一点需要认识到模块将依赖于文本包含的模型转变为语义导入模型。

为什么使用 export import 导出的宏与来自 #include 指令的宏行为不同？

候选人常常混淆宏的 export import 与常规宏行为。虽然 C++20 允许使用 export import 导出宏，但这些宏仅影响导入该模块的代码，并且不会超出导入范围泄漏。与 #include 不同，在 #include 中，宏在翻译单元中保持，直到显式取消定义或文件结束，而来自模块的导出宏仅限于导入翻译单元对该模块的暴露。此外，如果多个模块导出冲突的宏，则在导入时检测到冲突，而不是在编译后期导致静默重定义错误。这种范围行为提供了文本包含所缺乏的卫生性。

模块独立于预处理器如何影响构建系统集成和依赖扫描？

候选人常常忽视 C++20 模块要求构建系统在编译开始之前理解模块依赖性，而不是在编译期间发现依赖关系，因为头文件的依赖关系是在编译期间发现的。因为模块是编译单元，而不是文本文件，构建系统必须解析模块接口单元，以确定它们导出什么和导入什么。这需要一个两阶段的构建过程：首先，扫描模块接口单元以构建依赖图，然后按依赖顺序进行编译。预处理器的独立性意味着传统的用于头文件包含的 #ifdef 保护不再相关，并且基于宏的模块接口配置是有限的。构建系统必须跟踪编译的模块工件 (BMI - 二进制模块接口)，而不仅仅是源文件，从根本上改变了依赖跟踪和增量构建的方式。