为什么同为系统级编程语言，Rust 能拥有现代构建/包管理工具，C++ 却不能？

要理解为什么 Rust 拥有现代化的构建/包管理工具 (Cargo)，而 C++ 却普遍没有，我们需要深入探究它们各自的历史、设计哲学、生态系统以及技术挑战。

核心原因总结：

Rust 从零开始设计，可以将构建/包管理作为核心特性来考虑，并集成到语言本身。 Cargo 是语言的一部分，而不是事后添加的。
C++ 是一个历史悠久、演进缓慢的语言，其设计之初并未预见到现代软件开发的需求。 C++ 的复杂性、历史包袱以及缺乏统一的官方工具链，使得构建/包管理成为一个分散且碎片化的领域。

下面我们来详细阐述：



1. Rust：语言设计中的一体化

Rust 的设计团队在语言诞生之初就明确了构建和包管理的重要性。他们希望 Rust 能够提供一种开箱即用、高效且一致的开发者体验。因此，Cargo 被设计为 Rust 语言的核心组成部分，而不是一个可选的第三方工具。

Cargo 的优势及其背后原因：

统一的规范和命令： Cargo 提供了 `cargo build` (构建)、`cargo test` (测试)、`cargo run` (运行)、`cargo install` (安装) 等一系列标准的命令。开发者无需学习和配置不同的构建系统或脚本。
声明式依赖管理： `Cargo.toml` 文件清晰地定义了项目的元数据（名称、版本等）以及项目依赖的库（crates）。Cargo 会自动下载、编译和链接这些依赖，并处理版本冲突。
自动化的构建流程： Cargo 知道如何根据 `Cargo.toml` 中的信息来构建项目，包括依赖项的编译顺序、构建配置文件（debug/release）等。它还内置了对测试的支持。
版本管理和语义化发布： Cargo 支持 semver (语义化版本)，方便开发者管理依赖的版本范围。发布新的库（crate）到 `crates.io` (Rust 的官方包仓库) 也非常便捷。
集成工具链： Cargo 与 Rust 的编译器 (rustc) 紧密集成。它负责调用 `rustc`，并传递正确的编译参数。
生态系统的中心： `crates.io` 是 Rust 生态系统的核心，而 Cargo 是访问和使用 `crates.io` 的唯一官方入口。这形成了一个强大的正向循环，所有新的库都会首先考虑与 Cargo 兼容。
语言特性支持： Cargo 原生支持 Rust 的模块系统、特性（features）等语言层面的概念，使得依赖管理更加精细和灵活。

Rust 能够做到这一点，是因为：

语言诞生晚： Rust 在 2010 年开始发展，借鉴了许多现代语言的优点，也看到了其他语言在构建和包管理上的痛点。他们可以从一开始就将这些考虑进去。
集中的设计团队： Rust 的核心开发团队拥有对语言和相关工具链的绝对控制权，能够协调一致地推动这些现代化特性的实现。
社区的统一支持： Rust 社区迅速认识到 Cargo 的价值，并将其作为事实上的标准，极大地推动了 Cargo 的普及和发展。



2. C++：历史的包袱与碎片化的生态

C++ 是一门历史悠久、演进缓慢的语言。它的设计目标是“零成本抽象”，允许程序员尽可能接近底层硬件，同时提供面向对象的特性。然而，这种灵活性和对底层控制的强调，也带来了巨大的复杂性，尤其是在构建和依赖管理方面。

C++ 构建/包管理面临的挑战：

没有官方的构建/包管理工具： C++ 标准本身并没有规定如何构建项目或管理依赖。这是 C++ 与 Rust 最本质的区别。
庞大且多样化的现有工具链：
构建系统 (Build Systems)： 长期以来，C++ 项目依赖各种外部构建工具来处理编译、链接、配置等任务。
Make/Makefile： 最古老、最基础的构建工具，但编写和维护大型项目时非常繁琐，且平台兼容性差。
CMake： 目前最流行、最通用的跨平台构建系统生成器。它不直接构建，而是生成其他构建工具（如 Makefiles, Ninja files, Visual Studio projects）的配置文件。但 CMake 本身有其学习曲线和复杂性。
Meson, Bazel, Buck, SCons 等： 其他一些更现代或针对特定需求的构建系统，但它们都需要单独安装和配置，并且不是所有项目都迁移到这些新工具。
包管理器 (Package Managers)： C++ 的依赖管理是一个更大的痛点。
没有中心化官方仓库： C++ 没有像 `crates.io` 那样一个统一、官方的仓库来托管所有库。
各自为政的解决方案： 存在许多不同类型的包管理器，但没有一个能获得广泛的普遍支持：
系统包管理器 (apt, yum, brew, vcpkg, Conan 等)： 它们可以在操作系统层面安装库，但通常只管理系统级的安装，对于特定项目版本、交叉编译或本地开发来说不够灵活。
vcpkg： 由微软开发，旨在成为一个跨平台、开源的 C++ 包管理器。它支持从源代码构建库，并提供了一个集中的注册表。虽然非常有潜力，但其生态系统仍在发展中，并非所有库都已集成。
Conan： 另一个流行的 C++ 包管理器，专注于二进制包管理和跨平台。它也有一套自己的生态和工作流程。
FetchContent (CMake)： CMake 3.11+ 引入了 `FetchContent` 模块，允许在 CMake 脚本中直接拉取依赖的源代码，然后进行构建。这在一定程度上解决了依赖管理的问题，但仍然依赖于 CMake 的配置。
手动下载和编译： 许多 C++ 项目仍然依赖开发者手动下载库的源代码，并在自己的项目中进行编译和链接。这是最原始也是最容易出错的方式。
ABI 兼容性问题： C++ 的二进制接口 (ABI) 兼容性是一个非常复杂的问题。编译器版本、标准库版本、编译选项（如 `fPIC`）都会影响 ABI。一个库如果用不同的设置编译，可能就无法与另一个用不同设置编译的库链接。包管理器需要非常小心地处理这些兼容性。
复杂的编译模型： C++ 的编译模型包括预处理器、编译单元、模板实例化、链接等复杂过程，这使得构建过程本身就比 Rust 更难以自动化和标准化。
历史悠久的遗留代码： C++ 被广泛应用于各种领域，包括操作系统、嵌入式系统、游戏引擎等，这些领域往往对工具链有更严格的要求或存在大量遗留代码，迁移到新的构建/包管理工具非常困难。

为什么 C++ 难以拥有统一的现代工具：

语言的开放性和灵活性： C++ 的设计哲学允许开发者以各种方式解决问题，包括构建和依赖管理。这种自由度也导致了多样化的解决方案。
缺乏中央权威： C++ 没有一个像 Rust 团队那样能够强制推行统一标准的中央机构。C++ 标准委员会主要关注语言本身的进化，而非工具链的标准化。
生态系统的分散性： C++ 的生态系统极其庞大和分散，包含各种规模、各种目的的项目。任何统一的解决方案都需要能够兼容大量的现有代码和开发习惯。
技术障碍： 如前所述，ABI 兼容性、复杂的编译模型等技术挑战使得构建一个“一刀切”的包管理器非常困难。



3. 总结对比

| 特性 | Rust (Cargo) | C++ (多样化工具链) |
| : | : | : |
| 设计起源 | 作为语言核心特性，一体化设计 | 事后解决方案，工具链分散 |
| 官方工具 | 有（Cargo） | 无统一官方工具 |
| 包管理 | 统一的中央仓库 (`crates.io`)，声明式依赖管理 | 多样化（vcpkg, Conan, 系统包管理器, 手动下载），无统一仓库 |
| 构建系统 | 内置于 Cargo，简化流程 | 多样化（CMake, Make, Meson, Bazel 等），配置复杂 |
| 一致性 | 高，开发者体验统一 | 低，因工具链和配置而异 |
| 易用性 | 通常较高，开箱即用 | 学习曲线较陡，配置繁琐 |
| 生态支持 | Cargo 是生态的中心 | 生态碎片化，工具支持不一 |
| 技术挑战 | 相对较少（语言设计时考虑） | ABI 兼容性，复杂的编译模型，历史遗留代码 |

未来的展望：

尽管 C++ 在构建/包管理方面存在挑战，但社区正在努力改进。vcpkg 和 Conan 等项目取得了显著进展，CMake 的功能也在不断增强。未来可能会出现更通用的解决方案，但要达到 Rust Cargo 那样的统一和简洁，对于 C++ 而言仍将是一个漫长而艰难的过程，因为它需要克服语言本身的历史和生态系统的固有复杂性。

这方面C++欠缺的就是一个模块系统。

举例说吧。

假如要做一个C++包管理器，怎么管理不同库之间的依赖呢？

容易想到的一个方案就是每个库都提供一个入口头文件，编译一个项目时由包管理器自己生成一个文件，把编译的项目的这个入口头文件和所依赖的每个库的文件都在生成的这个文件里面#include一次，然后让编译器直接去编译这个生成的文件就好了。

现在你有两个问题。

首先是名字空间冲突的问题。这个好说，只要包管理器统一管理名字，让一个库只能独自占用一个顶级的名字空间就好。

然后，假使你的库是A，依赖B和C两个库，B和C又同时依赖一个库D。那么这样的菱形依赖怎么解决呢？也好办，让包管理器在生成编译文件的时候考虑到顺序，使得D的入口文件的包含总是发生在B和C的前面，并且使每个库只在其中出现一次，否则包管理器报错。

到目前为止事情还好办。

还是用上面的例子，你的库是A，依赖B和C两个库，B和C又同时依赖一个库D。

现在，D有一个类型X，库B和C都对类型X做了全局重载，比如说重载了X+X，这个时候重复了。

这时候包管理器当然要报错。问题是B和C都是独立开发的，这个错要让谁去修复？难道是你，A的作者？

阻碍上面的程序完成构建的规则在C++中称为ODR，One Definition Rule。

在支持全局重载的其他编程语言中，包括Rust，对这种窘况有一个规则叫做coherence，有时候叫做orphan rule。

在上面的例子中，如果换了Rust的情况，类型X归属于crate（指一个编译单元你可以理解为模块）D，+运算符也有归属，是std标准库。这个时候B和C都不允许在X上做X+【随便某个类型】的重载。

如果B的作者需要做类似的事，需要自己包装类型X产生一个新的类型Y，然后在Y上做+运算符的全局重载。

C++就算要去掉全局重载也是很尴尬的，比方说iostream的灵活性就依赖于全局重载。

如果想像Rust（以及其他ML语言）那样，可以在C++加个预处理指令放在编译单元的入口文件的开头，标明对这个编译单元所有的全局重载要遵循orphan rule，同时引入外部模块的概念，这样类型才能所属于某个模块。这样能够在编译的时候报错，而不是像ODR那样在链接的时候报错那就晚了。代价就是iostream肯定没法正常用了。

如果采用像C#那种做法，在需要模块化的代码中去掉全局重载的使用，把运算符重载放在静态成员函数上实现，这样在模板特化方面没法做，还是要引入模块系统，但是不失为另一种做法。

为什么同为系统级编程语言，Rust 能拥有现代构建/包管理工具，C++ 却不能？

为什么拉丁语、英语等欧洲语言以 10³ 为数字系统的级差，而东亚的汉语文化圈以 10⁴ 为级差？

为什么人类听觉系统进化为对 20 到 20000 赫兹范围内的声音敏感，而不是其他频率范围？

为什么鸿蒙系统的默认西文字体沿用了 Google 为 Android 设计的 Roboto?

日本92式重机枪的弹板供弹系统被诟病为一个败笔，为什么不直接在战场上改装成弹链供弹呢？

李亚普诺夫第一法（小干扰法）判断系统稳定性为什么当状态矩阵出现零根或实部为 0 的虚根的时候会失效？

为什么横扫千军系列能发展为多个游戏公司制作同一系列？

为何同系的虞国爵位为公，而吴国爵位为子？

X-Men系列为什么以金刚狼为线索人物？

为什么在晶体的布拉维系中，存在面心立方？面心立方可以转化为体心立方吗？

元成宗去世后，卜鲁罕皇后为什么要迎立非真金系的安西王阿难答为帝而不是其他真金系诸王？

圆柱绕流，在很小的雷诺数下为什么阻力系数反而很大（雷诺数为1时阻力系数大概10）？

为什么同为传统，中餐与酒可以保留很好，中医却要保护，西餐对中餐几乎没冲击，西医对中医的冲击却这么大？

为什么同为临海城市，秦皇岛成为了旅游胜地，而天津却只有集装箱和港口？

为什么同为亚洲四小龙，台湾的经济状况最差？

为什么同为游牧民族。中亚西亚很多民族都突厥化了，而蒙古人西征后却只能被各种文明所同化？

为什么同为中国人，同在一个体制下，我国女足要比男足强那么多呢？

为什么同为法国人，维克多·雨果被称作雨果而拿破仑·波拿巴被称为拿破仑？

为什么同为powerpc架构的处理器，xboxonex可以向下兼容x360而ps4不能兼容ps3？

为什么同为生物链顶端的生物，人类的数量远多于其他生物呢？