Rust on kenji.blog

将Rust的“所有权”与“借用”同C++指针进行比较解析

Sat, 12 Sep 2026 04:00:00 +0900

现代系统编程中，兼顾性能与内存安全是永恒的课题。多年来，C++一直作为该领域的王者而存在，但近年来Rust正在逐渐威胁其地位。Rust最大的特点在于不使用垃圾回收（GC）的情况下，在编译时通过“所有权（Ownership）”和“借用（Borrowing）”的概念来保证内存安全。

本文将详细比较C++的指针（原始指针、std::unique_ptr、std::shared_ptr）与Rust的所有权模型，并通过代码示例和图表，深入解析Rust的编译器（借用检查器）是如何防止释放后使用（Use-After-Free）和数据竞争（Data Race）的。

1. 内存管理基础：栈与堆

为了理解内存管理的基础，让我们先回顾一下程序是如何使用内存的。内存区域大致可分为“栈（Stack）”和“堆（Heap）”。

栈（Stack）

这是在函数调用时分配局部变量等数据的区域。它具有LIFO（后进先出）结构，内存的分配和释放非常快。只有在编译时能够确定大小的数据才会被放置在这里。

堆（Heap）

这里放置的是在运行时动态确定大小的数据，或者需要超越函数作用域存活的数据。通过指针（或引用）进行访问。

在没有垃圾回收的C++和Rust中，堆内存的管理成本可以用数学公式建模如下。假设对象总数为 $N$，分配的平均时间为 $T_{alloc}$，释放的平均时间为 $T_{dealloc}$，那么内存管理的总成本 $C_{memory}$ 为：

$$ C_{memory} = \sum_{i=1}^{N} (T_{alloc, i} + T_{dealloc, i}) + O_{sync} $$

这里 $O_{sync}$ 是多线程环境下的互斥控制（互斥锁或原子操作）所产生的开销。Rust在编译时决定内存释放的时机，因此在将运行时的垃圾回收导致的吞吐量下降（Stop-The-World）降至零的同时，在确切且安全的时机执行 $T_{dealloc}$。

graph TD A["程序内存"] --> B["栈（快速、固定大小）"] A --> C["堆（动态、较慢）"] B --> D["局部变量"] B --> E["指针/引用"] C --> F["动态分配的数据"] E -.->|"指向"| F

2. C++指针：自由与危险的权衡

让我们来看看C++中内存管理的变迁。

原始指针（Raw Pointers）时代及问题

从C语言继承而来的原始指针（*）提供了终极的自由，但同时也成为以下严重Bug的温床。

内存泄漏（Memory Leak）: 忘记使用delete释放通过new分配的内存。
悬垂指针（Dangling Pointer）: 访问在内存释放后（delete后）的指针。
双重释放（Double Free）: 对同一块内存区域执行了两次delete。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// C++: 原始指针引发问题的示例
void rawPointerExample() {
 int* ptr = new int(10);
 // ... 执行某些操作 ...
 delete ptr;

 // 错误地再次访问 (Use-After-Free / Dangling Pointer)
 // C++编译器无法将其作为编译错误处理
 std::cout << *ptr << std::endl; // 未定义行为（Undefined Behavior）
}

RAII与智能指针的登场 (C++11及以后)

自C++11起，基于RAII（Resource Acquisition Is Initialization，资源获取即初始化）概念的智能指针成为标准，不再推荐直接使用原始指针。

`std::unique_ptr`

表达单一所有权的指针。离开作用域时会自动释放内存。它无法被复制，只能“移动（Move）”所有权（使用std::move）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// C++: std::unique_ptr
#include <memory>
#include <iostream>

void uniquePtrExample() {
 std::unique_ptr<int> p1 = std::make_unique<int>(42);
 // std::unique_ptr<int> p2 = p1; // 编译错误（不可复制）
 std::unique_ptr<int> p3 = std::move(p1); // 所有权移动

 // C++的弱点：移动后p1变为nullptr，但访问操作本身可以通过编译
 // 在运行时会导致崩溃（段错误）
 // std::cout << *p1 << std::endl;
}

`std::shared_ptr`

允许多个指针共享同一对象的指针。它使用引用计数（Reference Counting），在计数变为0时释放内存。由于需要原子递增/递减操作，会产生一定的性能开销（相当于前述的 $O_{sync}$）。

3. Rust的所有权（Ownership）：范式转移

Rust将C++中std::unique_ptr的概念作为语言规范的基础，并拥有一个更严格的“所有权模型”。

所有权的3个规则

Rust的所有权系统基于以下三个极其简单的规则。

Rust中的每一个值都有一个被称为其所有者（owner）的变量。
在任何时候，值有且只有一个所有者。
当所有者离开作用域，这个值将被丢弃。

在Rust中，资源默认是“移动（Move）”的。即使不像C++那样显式调用std::move，赋值操作也会转移所有权。

1
2
3
4
5
6
7
8


// Rust: 所有权的移动（Move）
fn main() {
 let s1 = String::from("hello"); // 在堆上分配的数据
 let s2 = s1; // 所有权从s1移动到s2

 // 与C++最大的不同：对移动后的变量进行访问会导致“编译错误”！
 // println!("{}, world!", s1); // 编译错误: value borrowed here after move
}

这个“在编译时禁止访问移动后的变量”的特性，正是Rust比C++的std::unique_ptr更安全的原因之一。

sequenceDiagram participant S1 as "变量 s1" participant Heap as "堆内存 ('hello')" participant S2 as "变量 s2" S1->>Heap: "分配并拥有" Note over S1,S2: "let s2 = s1;" S1--xHeap: "失去所有权（无效化）" S2->>Heap: "获得所有权"

4. 借用（Borrowing）与引用

如果所有权总是被移动，那么每次向函数传递值时都必须将其所有权返回，这非常不便。因此便有了“借用（Borrowing）”。它相当于C++中的指针或引用。

Rust中的借用分为两种：

不可变引用（Immutable Reference）: &T （类似于C++的 const T&）
可变引用（Mutable Reference）: &mut T （类似于C++的 T&）

借用检查器（Borrow Checker）的冷酷法则

Rust编译器内置了“借用检查器”来验证引用的有效性。借用检查器强制执行以下严格规则：

在任意给定的作用域中，以下两者只能存在其一：

一个可变引用（&mut T）

任意数量的不可变引用（&T）

这被称为 “多读或单写（Multiple Readers XOR Single Writer, MRSW）” 原则。可以用数学上的异或（XOR）来表示，对于状态 $S$，不可变引用的数量 $N_r$ 和可变引用的数量 $N_w$ 必须满足以下约束：

$$ (N_r \ge 0 \land N_w = 0) \oplus (N_r = 0 \land N_w = 1) $$

通过这个规则，Rust在编译时彻底消除了数据竞争（Data Race）。数据竞争发生在：①两个或多个指针同时访问同一数据；②至少有一个指针在进行写入操作；③没有同步机制。Rust通过在编译时打破条件②，防患于未然地阻止了数据竞争。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// Rust: 违反借用规则导致的编译错误
fn main() {
 let mut s = String::from("hello");

 let r1 = &s; // 不可变借用 (OK)
 let r2 = &s; // 不可变借用 (OK)
 // let r3 = &mut s; // 错误！已经存在不可变借用，不能再创建可变借用

 println!("{}, {}", r1, r2);
}

5. 防止迭代器失效（Iterator Invalidation）

作为借用检查器发挥威力最具体的例子，让我们来看一个经典的Bug——“迭代器失效”。

C++中的迭代器失效（运行时崩溃）

在C++中，如果在循环遍历std::vector时修改它，背后的内存可能会被重新分配（Reallocation），导致引用变为悬垂指针。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


// C++: 迭代器失效Bug
#include <iostream>
#include <vector>

int main() {
 std::vector<int> v = {1, 2, 3};

 // 获取向量元素的引用
 int& first = v[0];

 // 添加元素（如果此时容量不足，将会分配新的内存区域，
 // 旧的区域可能会被丢弃）
 v.push_back(4);

 // first此时可能指向已经被释放的内存！（未定义行为）
 std::cout << "The first element is: " << first << std::endl;

 return 0;
}

Rust中的编译期防御

让我们用Rust编写完全相同的逻辑。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// Rust: 在编译时防止迭代器失效
fn main() {
 let mut v = vec![1, 2, 3];

 // 获取不可变引用 (借用开始)
 let first = &v[0];

 // 错误！当`first`对`v`进行不可变借用时，
 // 不能进行`v.push`所需的可变借用。
 // v.push(4);

 println!("The first element is: {}", first);
}

就像这样，Rust在编译器级别禁止“在读取值（不可变借用）的过程中对其进行修改（可变借用）”，因此能够确保在编译时捕获Use-After-Free和迭代器失效等致命Bug。

graph LR A["变量 v（所有者）"] --> B["堆数组 [1, 2, 3]"] C["引用 'first' (&v[0])"] -.->|"不可变借用"| B A -->|X "可变借用被拒绝！"| D["v.push(4)"] style C stroke:#00FF00,stroke-width:2px style D stroke:#FF0000,stroke-width:2px

6. Rust中的共享所有权：`Rc` 与 `Arc`

Rust也提供了相当于C++中std::shared_ptr的共享所有权，但根据单线程和多线程用途划分了明确的类型。

单线程用：`Rc<T>` (Reference Counted)

Rc<T> 是非线程安全的引用计数智能指针。由于不使用原子指令来递增或递减计数，在单线程中非常快。但是，如果试图将它发送到另一个线程，则会导致编译错误（因为它没有实现 Send trait）。

多线程用：`Arc<T>` (Atomic Reference Counted)

如果要在线程之间共享，需要使用进行原子递增和递减的 Arc<T>。其开销与C++的std::shared_ptr相当。

此外，在C++中，如果多个线程同时向std::shared_ptr共享的变量写入数据，会发生数据竞争。为了防止这种情况，必须手动正确地使用std::mutex。

而在Rust中，仅靠Arc<T>无法修改其内部的数据。如果需要修改，必须将其与互斥锁 Mutex<T> 结合使用。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
 // 线程安全共享与互斥控制的结合
 // 类似于C++的 std::shared_ptr<std::mutex>，但Mutex包含了数据
 let counter = Arc::new(Mutex::new(0));
 let mut handles = vec![];

 for _ in 0..10 {
 let counter_clone = Arc::clone(&counter);
 let handle = thread::spawn(move || {
 // 只有调用 lock() 才能获得内部的可变引用 (&mut i32)
 let mut num = counter_clone.lock().unwrap();
 *num += 1;
 }); // 依靠 RAII，离开作用域时会自动释放锁
 handles.push(handle);
 }

 for handle in handles {
 handle.join().unwrap();
 }

 println!("Result: {}", *counter.lock().unwrap());
}

值得特别注意的是，Rust的Mutex<T>不仅是一个锁机制，更重要的一点是它**“将受保护的数据包含在了类型内部”**。通过这种方式，可以在编译级别彻底防止“忘记获取锁就访问数据”的错误。如果不获取锁（lock()），就无法获得内部数据的访问权（引用）。

总结：编译器的“事前检查”还是开发者的“自我责任”

C++的指针和智能指针为开发者提供了高度的控制和性能，但它们的正确使用依赖于开发者的自律。RAII和std::unique_ptr的引入使得C++的安全性大幅提升，但即使如此，也无法在语言级别完全防止移动后的访问或迭代器失效等“未定义行为”。

相反，Rust通过将所有权（Ownership）和借用（Borrowing）规则嵌入编译器，在编译时而非运行时检测这些错误。“只要能编译通过，内存就是安全的”，这种强有力的保证正是Rust在系统编程领域迅速获得支持的最大理由。

与Rust的借用检查器作斗争（Fight the borrow checker）对初学者来说是一大障碍，但这只不过是编译器在严格代替C++程序员原本在脑海中进行的追踪指针生命周期的复杂计算罢了。

如果在理解了C++指针的自由与危险之后再学习Rust，您一定能更深刻地体会到所有权模型背后“为何要采取这种设计”的哲学。

本文是关于C++和Rust内存管理方法的比较探讨。希望能够为您根据不同项目的需求选择合适的语言提供参考。

C++工程师学习Rust后体会到的优缺点

Sat, 12 Sep 2026 03:00:00 +0900

引言：系统编程的新黎明

在现代软件工程中，C++和Rust是站在系统编程最前沿的两大巨头。多年来，在操作系统、嵌入式设备、游戏引擎、高频交易（HFT）系统等需要发挥硬件极限性能的领域，C++一直作为绝对的王者君临天下。作为一名资深C++工程师，我自己也是从C++98时代的裸指针丛林开始，经历了C++11的现代化浪潮（智能指针、Lambda表达式、auto的引入），并伴随着C++14/17/20规范的不断庞大，一直坚持编写代码至今。

然而近年来，作为C++结构性问题——特别是“缺乏内存安全”导致的安全漏洞（据说约70%的CVE源于内存问题）以及“无止境复杂化的规范和未定义行为（UB）”——的解决方案，Rust正在戏剧性地崛起。被Linux内核正式采用，以及微软、谷歌、AWS等科技巨头大规模向Rust迁移的项目，并不只是短暂的流行，而是意味着系统编程领域范式的转变。

在本文中，我将作为一名纯正的C++工程师，从涉及语言规范根本的技术视角，彻底比较并剖析在深入学习Rust并将其应用于实战后所体会到的“优点”和“缺点”。

1. 内存管理的范式转变：从RAII到所有权与借用

C++的RAII与智能指针的局限性

C++最伟大的发明之一是RAII（资源获取即初始化）。在构造函数中获取资源，在离开作用域时通过析构函数自动释放资源的理念，将开发者从手动使用new和delete导致的内存泄漏恐惧中解放出来。从C++11开始，std::unique_ptr和std::shared_ptr被引入标准库，使得所有权（Ownership）的概念可以在代码中表达。

但是，C++的智能指针和移动语义有一个致命的弱点：编译器进行的静态验证是不完整的。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


#include <iostream>
#include <memory>
#include <string>

void consume(std::unique_ptr<std::string> ptr) {
 std::cout << "Consuming: " << *ptr << std::endl;
}

int main() {
 auto my_ptr = std::make_unique<std::string>("Hello, C++");

 // 将所有权移动（Move）给函数
 consume(std::move(my_ptr));

 // 危险：在C++中，访问移动后的对象不会产生编译错误
 // std::move仅仅是转换为右值引用（T&&）的强制类型转换，编译器不会阻止其使用
 if (my_ptr) {
 std::cout << "Pointer is still valid?" << std::endl;
 } else {
 std::cout << "Pointer is null." << std::endl;
 }

 // std::cout << *my_ptr << std::endl; // 释放后使用（Use-After-Free）导致的未定义行为
 return 0;
}

在C++中，始终存在由于误访问被std::move掏空（处于有效但未指定状态）的对象而带来的风险。这会导致运行时崩溃，最坏的情况下还会直接引发安全漏洞。

Rust的所有权（Ownership）与借用检查器的绝对防御

Rust将“所有权”这一概念融入了语言的核心设计中，并通过称为**借用检查器（Borrow Checker）**的编译器功能进行严格的静态分析。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


fn consume(s: String) {
 println!("Consuming: {}", s);
} // 在这里 s 离开作用域，内存被释放（Drop）

fn main() {
 let my_string = String::from("Hello, Rust");

 // 将所有权移动给函数。在Rust中，默认就是移动语义。
 consume(my_string);

 // 编译错误！绝对无法访问被移动后的变量
 // println!("Is it still there? {}", my_string);
}

在Rust中，当变量的所有权转移时，原变量会被编译器视为“未初始化”状态，从而彻底阻断后续的访问。这使得“释放后使用（Use-After-Free）”或“悬垂指针（Dangling Pointer）”等漏洞在理论上根本无法通过编译。

graph TD A["C++ std::unique_ptr"] --> B["应用 std::move"] B --> C["所有权转移"] C --> D["旧指针仍然可访问"] D --> E["潜在的未定义行为 (UB)"] F["Rust Box / String"] --> G["按值传递 (移动)"] G --> H["所有权转移"] H --> I["编译器阻断旧变量"] I --> J["保证内存安全"]

借用（Borrowing）与可变性的控制

更为强大的是引用资源的“借用（Borrowing）”规则。在Rust中，强制执行以下规则：

在任何给定的时间点，要么只能存在“多个不可变引用（&T）”，要么只能存在“一个可变引用（&mut T）”，二者只能选其一。
引用的生命周期不能超过其原始数据的作用域（生命周期的限制）。

在C++中，可以轻松地对同一个对象创建多个可变引用或指针，这常常会引起意想不到的状态破坏（如迭代器失效等）。Rust通过在语言层面上禁止这种“别名（Aliasing）+ 可变性（Mutability）”的组合，将漏洞扼杀在摇篮里。

2. 内存布局与智能指针的数学开销

在系统编程中，对内存布局的准确理解是不可或缺的。让我们比较一下C++的std::shared_ptr和Rust的std::rc::Rc / std::sync::Arc。

C++的std::shared_ptr通过引用计数来管理资源，但它默认使用线程安全的原子操作（std::atomic）来增加或减少引用计数。其内存开销可以用如下公式表示：

$$ Overhead_{C++} = sizeof(T) + sizeof(ControlBlock) $$

这里，$ControlBlock$ 包含“强引用计数（Strong Ref Count）”、“弱引用计数（Weak Ref Count）”以及“自定义删除器（Custom Deleter）”。问题在于，即使只在单线程环境下使用，原子指令的开销（如缓存行锁定等）也会无条件地产生。

相比之下，Rust根据用途对智能指针进行了严格的区分。

单线程专用: Rc<T> (Reference Counted)
多线程专用: Arc<T> (Atomic Reference Counted)

$$ Overhead_{Rc} = sizeof(T) + 2 \times sizeof(usize) $$ $$ Overhead_{Arc} = sizeof(T) + 2 \times sizeof(AtomicUsize) $$

在Rust中，只要使用单线程专用的Rc<T>，就能完全避免原子操作带来的性能惩罚（零成本抽象）。而且，借助后文将要提到的线程安全机制，将Rc<T>错误地传递给另一个线程的行为会被类型系统完全阻止。

3. 线程安全：“无畏并发”的冲击

在C++中进行多线程编程，总是伴随着数据竞争和死锁的恐惧。

C++互斥锁与数据分离的危险性

C++的std::mutex仅仅是对“特定的代码块（临界区）”进行排他控制，“需要保护的数据”与“互斥锁”之间在语言层面上没有任何绑定关系。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


#include <iostream>
#include <thread>
#include <mutex>
#include <vector>

std::vector<int> shared_data;
std::mutex mtx;

void worker() {
 // 即使开发者忘记获取锁，编译也能正常通过
 // std::lock_guard<std::mutex> lock(mtx);
 shared_data.push_back(1); // 致命的数据竞争！
}

int main() {
 std::thread t1(worker);
 std::thread t2(worker);
 t1.join();
 t2.join();
 return 0;
}

Rust的互斥锁“所有”数据

在Rust中，Mutex<T>通过泛型将要保护的数据类型 T **包裹（所有）**在内部。为了访问数据，必须调用lock()获取一个守卫对象。在不获取锁的情况下接触数据，在语法上是不可能的。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
 // 数据被完全封装在Mutex内部
 let shared_data = Arc::new(Mutex::new(Vec::new()));
 let mut handles = vec![];

 for _ in 0..2 {
 // 为了在线程间共享，克隆Arc（线程安全的引用计数）
 let data_clone = Arc::clone(&shared_data);
 let handle = thread::spawn(move || {
 // 如果不获取锁，就无法访问内部的Vec
 let mut data = data_clone.lock().unwrap();
 data.push(1);
 });
 handles.push(handle);
 }

 for handle in handles {
 handle.join().unwrap();
 }
}

此外，Rust中还有两个保证并发安全的核心特征（Trait）：

Send：可以在线程间安全地转移所有权的类型
Sync：可以被多个线程同时安全引用的类型

例如，非线程安全的Rc<T>没有实现Send特征。因此，如果试图将其传递给thread::spawn，会立刻引发编译错误。这种“无畏并发（Fearless Concurrency）”将开发者从漏洞的恐惧中解放出来，从而可以更加激进地推进并行化。

根据阿姆达尔定律（Amdahl’s Law），对于可并行化的部分 $P$ 和并行度 $N$ ，理论上的最大吞吐量可以表示为：

$$ S(N) = \frac{1}{(1 - P) + \frac{P}{N}} $$

借助类型系统，Rust使得为了最大化该 $P$ 值而进行的重构变得极其安全。

graph TD A["C++ 线程安全"] --> B["依赖开发者的记忆"] B --> C["互斥锁与数据解耦"] C --> D["极易产生静默的数据竞争"] E["Rust 线程安全"] --> F["Send 和 Sync 特征"] F --> G["互斥锁拥有数据"] G --> H["在编译期防止数据竞争"]

4. 错误处理：异常 vs 代数数据类型

C++的标准错误处理机制是“异常（Exceptions）”。然而，异常会让控制流变得不透明，并带来性能损失（如栈展开或RTTI膨胀）。在嵌入式系统和游戏引擎中，经常会完全禁用异常（-fno-exceptions），并采用返回传统错误代码的设计。虽然C++23引入了std::expected，但要渗透到整个生态系统中还需要时间。

Rust中不存在异常的概念。错误被作为纯粹的“值”返回，并用 Result<T, E> 这个枚举类型（代数数据类型）来表示。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


use std::fs::File;
use std::io::{self, Read};

// 仅通过查看返回值类型，就可以明确可能会发生IO错误
fn read_file_content(path: &str) -> Result<String, io::Error> {
 // 如果发生错误，? 运算符会立即提早返回；如果成功，则取出其中的内容
 let mut file = File::open(path)?;
 let mut content = String::new();
 file.read_to_string(&mut content)?;
 Ok(content)
}

这个 ? 运算符是革命性的。它消除了在C++中检查错误代码时产生的深层嵌套（if语句金字塔），在保持类似异常那种整洁代码流的同时，还可以显式地指出错误是在哪个函数调用中传播的。

5. 多态性：从虚函数/模板到特征（Trait）

C++的多态主要通过类的继承和虚函数（virtual）实现的动态分发，或通过模板实现的静态分发（如CRTP等）来实现。

在动态分发中，对象内部嵌入了指向虚函数表（vtable）的指针（vptr），在调用函数时会产生解析指针的开销。

$$ T_{dispatch} = T_{lookup\_in\_vtable} + T_{dereference} $$

Rust摒弃了经典面向对象中的“类继承”，取而代之采用了“特征（Traits）”的概念（类似于C++20的Concept，但功能更强大）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


trait Drawable {
 fn draw(&self);
}

struct Circle { radius: f64 }
impl Drawable for Circle {
 fn draw(&self) { println!("Drawing a Circle of radius {}", self.radius); }
}

// 静态分发 (单态化・零开销)
fn draw_static<T: Drawable>(item: &T) {
 item.draw();
}

// 动态分发 (特征对象)
fn draw_dynamic(item: &dyn Drawable) {
 item.draw();
}

Rust动态分发（dyn Trait）最大的特点是，数据结构内部不包含vptr，而是使用胖指针（Fat Pointer）。胖指针成对地保存“指向数据的指针”和“指向vtable的指针”。这使得对外部库定义的类型进行事后特征实现（扩展）并应用于动态分发变得非常容易。

6. 包管理与构建系统：CMake的苦恼与Cargo的恩惠

C++最大的弱点之一就是缺乏标准的包管理器。CMakeLists.txt晦涩难懂的语法、使用find_package解决依赖关系的复杂性，以及不同操作系统库路径的差异，持续吞噬着C++工程师大量的时间。

而在Rust中，标准搭载了Cargo这款世界上最顶级的包管理器兼构建系统。

graph TD A["C++ 构建环境"] --> B["CMakeLists.txt"] B --> C["vcpkg / Conan 集成"] C --> D["生成 Makefiles / Ninja"] D --> E["编译器 (GCC/Clang/MSVC)"] F["Rust 构建环境"] --> G["Cargo.toml"] G --> H["从 crates.io 获取依赖"] H --> I["rustc (Cargo build)"] I --> J["可执行二进制文件"]

只需在 Cargo.toml 中加上一行依赖库（Crate）的名称和版本，推移依赖的解决、下载、构建等所有过程都会全自动完成。不仅如此，测试（cargo test）、文档生成（cargo doc）、静态分析（cargo clippy）、代码格式化（cargo fmt）等开发所需的工具链全部集成在这个单一命令中。这种舒适感具有一旦体验过就不想再回到C++构建环境的破坏力。

7. 学习Rust的缺点与学习曲线

到目前为止，我已经讲述了Rust的优点，但是C++工程师在将Rust投入实战时，也肯定会面临一些“高墙”和缺点。

1. 与严苛的借用检查器搏斗

如果我们试图将C++中“随便用裸指针连接”的数据结构（例如双向链表、图结构、自引用结构体等）原封不动地在Rust中实现，会因为所有权和生命周期的限制而无法通过编译。为了满足借用检查器，我们需要使用 Rc<RefCell<T>> 进行复杂的包装，或者从根本上重新设计，改用Arena分配器或基于索引的管理。

2. 漫长的编译时间

虽然C++也会因为模板嵌套而导致编译变慢，但Rust的编译时间（特别是从零开始的干净构建）也绝对不算短。由于LLVM强大的优化过程、宏展开以及泛型的单态化（Monomorphization）相互叠加，在大型项目中构建时间会成为瓶颈。开发过程中必须经常使用 cargo check 等技巧来应对。

3. 与C++代码库的互操作性

与C语言（FFI）的互操作非常顺畅，但是要将Rust与现有庞大的C++代码库（大量使用了类、模板、虚函数）直接连接起来却非常困难。近年来，虽然 cxx 和 autocxx 等桥接工具正在发展，但要实现完全无缝的迁移仍然面临很高的门槛。

总结：我们应该转向Rust吗？

未来，C++仍将在游戏引擎开发以及现有庞大基础设施中继续扮演重要角色。C++20/23带来的现代化进程也引人瞩目，使得代码编写变得越来越安全。

然而，在“新启动的系统编程项目”中，我觉得越来越难找到不选择Rust的理由了。只要通过编译，就能从未定义行为和内存破坏的恐惧中解脱出来，并以高性能安全地进行并发处理——Rust带来的这种“确定性”极大地改善了工程师的心理模型。

对于C++工程师而言，学习Rust不仅仅是记住新的语法，更是一次绝佳的体验，让你在“如何安全管理内存和线程”方面获得全新的视野。请大家也务必亲自体验一下Cargo的舒适与借用检查器的严苛。