Rust on kenji.blog

用C++指標來比較並解說Rust的「所有權」與「借用」

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）

執行時才會動態決定大小的資料，或者是需要超越函式作用域（Scope）而持續存在的資料，會被配置在此處。它必須透過指標（或參考）來進行存取。

在沒有垃圾回收機制的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）: 忘記對 new 出來的記憶體執行 delete。
懸空指標（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，但存取行為本身是可以編譯的
 // 會在執行時引發崩潰（Segmentation Fault）
 // std::cout << *p1 << std::endl;
}

`std::shared_ptr`

這是一種允許多個指標共用同一個物件的指標。它使用參考計數（Reference Counting），當計數歸零時就會釋放記憶體。由於需要進行原子的增減操作，因此會產生些許的效能開銷（相當於前述的 $O_{sync}$）。

3. Rust的所有權（Ownership）：典範轉移

Rust將C++中 std::unique_ptr 的概念視為語言規範的核心，並擁有更加嚴格的「所有權模型」。

所有權的3個規則

Rust的所有權系統建立在以下3個極其簡單的規則之上。

Rust中的每一個值，都有一個被稱為其擁有者（owner）的變數。
任何時候，擁有者都只能有一個。
當擁有者離開作用域時，該值就會被丟棄。

在Rust中，資源預設是會被「移動」的。即使不像C++那樣明確寫出 std::move，所有權也會透過賦值操作而轉移。

1
2
3
4
5
6
7
8


// Rust: 所有權的移動（Move）
fn main() {
 let s1 = String::from("hello"); // 配置在堆積中的資料
 let s2 = s1; // 所有權從s1移動（Move）到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的編譯器內建了驗證參考正確性的「借用檢查器」。借用檢查器會強制執行以下嚴格的規則。

在任意的作用域中，只能存在以下其中一種情況。

1個可變參考（&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) $$

透過這個規則，在編譯時期就能完全排除資料競爭（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> 是一種非執行緒安全（Non-thread-safe）的參考計數智慧指標。因為它不使用原子指令來增減計數，所以在單一執行緒內非常快速。然而，如果試圖將它傳送到另一個執行緒，就會產生編譯錯誤（因為它沒有實作 Send 特徵）。

多執行緒用：`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是站在系統程式設計最前線的兩大巨頭。長年以來，C++在作業系統、嵌入式裝置、遊戲引擎、高頻交易（HFT）系統等需要發揮硬體極限效能的領域中，一直以絕對王者的姿態君臨天下。我本身也是一位資深C++工程師，從C++98時代的原始指標叢林開始，一路伴隨著C++11現代化浪潮（引進智慧指標、Lambda表達式、auto），以及C++14/17/20不斷龐大化的規範編寫著程式碼。

然而近年來，為了解決C++所面臨的結構性問題——特別是因「缺乏記憶體安全性」造成的安全漏洞（據說約7成的CVE起因於記憶體問題）以及「無止盡複雜化的規範與未定義行為（UB）」——Rust的強勢崛起提供了解決方案。Linux核心正式採用Rust，以及Microsoft、Google、AWS等科技巨頭進行的大規模Rust轉移專案，這不僅僅是一時的流行，更意味著系統程式設計正經歷典範轉移。

本篇文章將由一位道地的C++工程師，從語言規範核心的技術觀點出發，深入比較並解說實際深入學習Rust、並在實戰中使用後所感受到的「優點」與「缺點」。

1. 記憶體管理的典範轉移：從RAII到所有權與借用

C++的RAII與智慧指標的極限

C++最偉大的發明之一就是RAII (Resource Acquisition Is Initialization)。在建構函式中取得資源，並在離開作用域時透過解構函式自動釋放，這個概念將開發者從手動使用new與delete造成的記憶體洩漏恐懼中解放出來。從C++11開始，std::unique_ptr與std::shared_ptr被導入標準函式庫，讓所有權（Ownership）的概念能在程式碼上表現出來。

但是，C++的智慧指標與移動語意（Move Semantics）有一個致命的弱點，那就是編譯器的靜態驗證並不完美。

 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（迷途指標）」等Bug，在理論上根本無法通過編譯。

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. 執行緒安全：“Fearless Concurrency” 的衝擊

在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的Mutex「擁有」資料

在Rust中，Mutex<T>使用泛型將受保護的資料型別 T **內含（擁有）**在其中。為了存取資料，必須呼叫lock()來取得守衛物件（Guard Object）。如果不取得鎖就想觸碰資料，在語法上是不可能的。

 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（無懼並行）」讓開發者從Bug的恐懼中解放出來，能夠更積極地推動平行化。

根據阿姆達爾定律（Amdahl’s Law），可平行化部分 $P$ 與平行度 $N$ 之下的理論最大吞吐量可表示如下：

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

Rust讓你可以依賴型別系統，極度安全地進行重構，以最大化這個 $P$ 值。

graph TD A["C++ 執行緒安全"] --> B["依賴開發者的記憶力"] B --> C["Mutex與資料分離"] C --> D["高風險的靜默資料競爭"] E["Rust 執行緒安全"] --> F["Send與Sync特徵"] F --> G["Mutex擁有資料"] 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. 多型：從虛擬函式・樣板到特徵

C++的多型主要是透過類別繼承與虛擬函式（virtual）的動態分派（Dynamic Dispatch），或是透過樣板的靜態分派（如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解決相依性問題的複雜度，以及各個OS之間函式庫路徑的差異，持續奪走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. 與嚴酷借用檢查器的搏鬥

如果在Rust中試圖直接實作C++裡「隨便用原始指標串接」的資料結構（例如雙向鏈結串列、圖結構、自我參考結構等），會因為所有權與生命週期的限制而無法通過編譯。為了解決借用檢查器的問題，必須進行像 Rc<RefCell<T>> 這樣複雜的包裝，或者從根本上重新設計，改用區域分配器（Arena Allocator）或基於索引的管理方式。

2. 漫長的編譯時間

雖然C++也會因為樣板巢狀而導致編譯緩慢，但Rust的編譯時間（特別是從零開始的乾淨建置）也絕不算短。由於LLVM強大的最佳化流程、巨集展開、泛型的單態化（Monomorphization）等因素疊加，在大型專案中建置時間將成為瓶頸。在開發過程中，必須經常運用 cargo check 等技巧。

3. 與C++程式碼庫的互通性

雖然與C語言（FFI）的整合非常順暢，但要將既存的龐大C++程式碼庫（大量使用類別、樣板、虛擬函式）直接與Rust整合卻非常困難。近年來雖然有 cxx 或 autocxx 等橋接工具不斷進化，但要達到完全無縫的轉移仍然有很高的門檻。

總結：我們應該轉移到Rust嗎？

C++未來在遊戲引擎開發以及既存的龐大基礎設施中，仍將繼續扮演重要的角色。C++20/23帶來的現代化也非常顯著，使得撰寫程式碼變得更安全。

然而，在「全新啟動的系統程式設計專案」中，我覺得現在已經很難找到不選擇Rust的理由了。只要能通過編譯，就能從未定義行為與記憶體破壞的恐懼中解放出來，並能以高效能安全地進行並行處理，Rust這種「確定性」大幅改善了工程師的心智模型。

對C++工程師而言，學習Rust不單只是記住新的語法，而是獲得對「安全管理記憶體與執行緒的方法」全新視角的最佳體驗。請大家務必親身體會看看Cargo的舒適與借用檢查器的嚴格。