我们需要认真思考 C++ 模块的出路

摘要

本文作者对C++模块的现状提出尖锐批评。模块最初承诺大幅缩短编译时间，但经过五年多的开发，这一核心目标似乎已被淡化。作者指出模块面临的根本问题：编译器与构建系统之间缺乏有效协调、过度前置设计违背了渐进式开发原则、缺乏统一的产品负责人推动跨组织协作。若无法证明在真实项目中实现5倍以上的编译加速，作者建议放弃模块标准化。

内容框架与概述

文章开篇即抛出颇具争议的论点：若C++模块无法展示5-10倍的编译加速效果，就应该从标准中移除。作者追溯了模块的历史，指出2018-2019年投票通过时，快速编译是核心卖点，但如今焦点已转向"构建隔离"等次要收益。虽然避免宏泄漏等问题有价值，但这些问题远不如每天困扰开发者的编译速度瓶颈重要。

作者深入剖析了模块陷入困境的原因。首先是政治层面的决策失误——尽管有人明确指出实现难度，模块仍被强推进C++ 20标准。其次是技术协作的失败——模块需要编译器与构建系统紧密配合，但ISO标准甚至不承认源码存放于文件这一事实，导致各方各自为政。作者亲历的讨论中，某编译器团队以"不想把编译器变成构建系统"为由否决所有提案。

文章后半部分提出了建设性意见。作者认为正确的做法是渐进式开发：先实现最小可用功能，在10个源文件的项目上验证，逐步扩展到100、1000个文件，每步都测量性能。如果无法获得预期收益，就应及时止损。作者对import std持谨慎乐观态度，认为这是正确的迭代方向，但即便如此，实际效果仍不够理想。最终结论是：模块必须证明自身价值，否则应集中资源解决其他问题。

核心概念及解读

O(N²)头文件包含问题：传统C++的头文件机制导致编译复杂度呈平方级增长，每个源文件都需重新解析所有包含的头文件，这是模块试图解决的根本问题。

构建隔离(Build Isolation)：模块的次要收益，指避免宏泄漏、命名空间查找异常等问题。作者认为这些问题虽然"令人不适"，但发生频率远低于编译慢的普遍痛苦。

前置大设计(Grand Design Up Front)：违背软件工程"标准化现有实践"原则的做法。C++模块在没有原型、测试代码的情况下被标准化，是计算领域最极端的前置设计案例之一。

import std：一种渐进式模块化方案，仅将标准库模块化。由于标准库无外部依赖且占编译时间大头，这是相对务实的切入点，但目前收益仍不够显著。

沉没成本谬误：作者警告，不应因已投入大量资源就继续追加投入。若模块无法兑现承诺，理性选择是止损而非继续喂养这一谬误。

原文信息

此摘要卡片由 AI 自动生成