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 将为假

int main() {
    double result = compute(10.0);  // 一切正常
}

生活中的情况

一家公司维持着一个大型代码库，代码行数达到数百万，涉及数百个模块。他们依赖于一个遗留的数学库，该库在其公共头文件中定义了 MIN 和 MAX 等宏。这些宏经常与标准库函数和第三方 JSON 解析库产生冲突，这些库使用 min 和 max 作为变量名或函数模板。

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

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

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

候选人常常忽视的内容

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

候选人常常忽视，C++20 模块生成的编译模块接口单元（CMI）是模块导出接口的二进制表示。与由预处理器处理并包含宏定义作为文本的文本头文件不同，CMI 存储有关导出函数、类型和模板的语义信息。

预处理器不会处理导入模块的内容；它只看到导入声明。因此，在模块实现或其接口单元中定义的宏对导入者不可见。这与 #include 的根本不同，因为 #include 字面意义上复制了包括 #define 指令的文本。

理解这一点需要认识到模块从文本包含模型转变为语义导入模型。二进制格式确保只有明确定义导出的实体可见，宏不属于导出接口，除非通过宏指令明确定义导出。

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

候选人常常混淆宏的 export import 与常规宏行为。虽然 C++20 允许通过 export import 导出宏，但这些宏仅影响导入模块的代码，并且不会超出该导入范围泄漏。

与 #include 不同，后者宏在翻译单元中持续存在，直到明确定义未定义或文件结束，从模块导出的宏仅限于导入翻译单元对该模块的可见性。预处理器将导入的宏视为在导入时定义，但它们并不会以与文本包含相同的方式影响后续导入或全局预处理器状态。

此外，如果多个模块导出冲突的宏，冲突在导入时会被检测，而不是在编译稍后造成静默重新定义错误。这种作用域行为提供了文本包含所缺乏的卫生，确保宏的行为更像适当的命名空间作用域实体。

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

候选人常常忽视，C++20 模块要求构建系统在编译开始之前理解模块依赖性，而不是在编译过程中发现头文件依赖性。因为模块是编译单元而不是文本文件，构建系统必须解析模块接口单元，以确定它们所导出的和所导入的内容。

这需要一个两阶段的构建过程：首先，扫描模块接口单元以构建依赖图，然后按依赖顺序进行编译。预处理器的独立性意味着传统的 #ifdef 保护措施对于头文件包含无关紧要，基于宏的模块接口配置受到限制。构建系统必须跟踪编译的模块工件（BMI - 二进制模块接口），而不仅仅是源文件。

这从根本上改变了依赖跟踪和增量构建的工作方式。构建系统现在必须将 BMI 文件作为中间工件进行管理，拥有自己的依赖链，需要对构建工具如 CMake 或 Bazel 进行更新，以支持模块感知的编译图。