技术解读：现代化工具链在大规模 C++ 项目中的运用

编者按：C++ 语言与编译器一直都在持续演进，出现了许多令人振奋的新特性，同时还有许多新特性在孵化阶。除此之外，还有许多小更改以提高运行效率与编程效率。本文整理自全球 C++ 及系统软件技术大会上的精彩分享，接下来由作者带我们了解 C++ 项目的实践工作等具体内容，全文整理如下：

介绍

C++ 是一门有着长久历史并依然持续活跃的语言。C++ 最新标准已经到了 C++23。Clang/LLVM、GCC 与 MSVC 等三大编译器都保持着非常频繁的更新。除此之外的各个相关生态也都保持着持续更新与跟进。但遗憾的是，目前看到积极更近 C++新标准与 C++新工具链的都主要以国外项目为主。国内虽然对 C++ 新标准也非常关注，但大多以爱好者个人为主，缺乏真实项目的跟进与实践

本文以现代化工具链作为线索，介绍我们实际工作中的大型 C++ 项目中现代化工具链的实践以及结果。

对于 C++ 项目，特别是大型的 C++项目而言，常常会有以下几个特点（或痛点）：

• 项目高度自治 – 自主决定编译器版本、语言标准
• 高度业务导向 – 少关注、不关注编译器和语言标准
• 先发劣势 – 丧失应用新技术、新特性的能力
• 沉疴难起 – 编译器版本、语言标准、库依赖被锁死

许多 C++ 项目都是高度自治且业务导向的，这导致一个公司内部的 C++ 项目的编译器版本和语言标准五花八门，想统一非常困难。同时由于日常开发主要更关心业务，时间一长背上了技术债，再想用新标准与新工具链的成本就更高了。一来二去，编译器、语言标准与库依赖就被锁死了。

同时对于业务来说，切换编译器也会有很多问题与挑战：

• 修复更严格编译器检查的问题
• 修复不同编译器行为差异的问题
• 修复语言标准、编译器行为改变的问题 – 完善测试
• 二进制依赖、ABI兼容问题 – 全源码编译/服务化
• 性能压测、调优

这里的许多问题哪怕对于有许多年经验的 C++工程师而言可能都算是难题，因为这些问题其实本质上是比语言层更低一层的问题，属于工具链级别的问题。所以大家觉得棘手是很正常的，这个时候就需要专业的编译器团队了。

在我们的工作中，少数编译器造成的程序行为变化问题需要完善的测试集，极少数编译器切换造成的问题在产线上暴露出来 – 本质是业务/库代码的 bug，绝大多数问题在构建、运行、压测阶段暴露并得到修复。

这里我们简单介绍下我们在实际工作中遇到的案例：

业务1（规模5M）

• 业务本身10+仓库；三方依赖50+，其中大部分源代码依赖，部分二进制依赖。
• 二进制依赖、ABI兼容问题 – 0.5人月；编译器切换、CI、CD – 1.5人月；性能分析调优 – 1人月。

业务2（规模7M）

• 二方/三方依赖 30+，二进制依赖。
• 编译器切换改造 – 2 人月；性能压测调优 – 1 人月。

业务3（规模3M）

• 二方/三方依赖 100+，多为二进制依赖。
• 二进制依赖、ABI 兼容问题 – 预估 2 人年。

在切换工具链之后，用户们能得到什么呢？

• 更短的编译时间
• 更好的运行时性能
• 更好的编译、静态、运行时检查
• 更多优化技术 – ThinLTO、AutoFDO、Bolt 等
• 更新的语言特性支持 – C++20 协程、C++20 Module 等
• 持续性更新升级 – 良性循环

其中更短的编译时间本身就是 clang 的一个特性，从 gcc 切换到 clang 就会得到很不错的编译加速。同时运行时性能也一直是编译器的目标。而各种各样的静态与运行时检查也是编译器/工具链开发的一个长期主线。另外更新的工具链也会带来更多的优化技术与语言特性支持，这里我们后面会重点介绍。最后是我们可以得到一个长期持续性更新升级的良性循环，这一点也是非常重要和有价值的。

优化技术简介

ThinLTO

传统的编译流程如下图所示

编译器在编译 *.c 文件时，只能通过 *.c 及其包含的文件中的信息做优化。

LTO （Linking Time Optimization）技术是在链接时使用程序中所有信息进行优化的技术。但 LTO 会将所有 *.o 文件加载到内存中，消耗非常多的资源。同时 LTO 串行化部分比较多。编译时间很长。落地对环境、技术要求比较高，目前只在 suse 等传统 Linux 厂商中得到应用。

为了解决这个问题，LLVM 实现了 ThinLTO 以降低 LTO 的开销。

GCC WH