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["Program Memory"] --> B["Stack (Fast, Fixed Size)"] A --> C["Heap (Dynamic, Slower)"] B --> D["Local Variables"] B --> E["Pointers/References"] C --> F["Dynamically Allocated Data"] E -.->|"Points to"| F

2. C++のポインタ：自由と危険のトレードオフ

C++におけるメモリ管理の変遷を見てみましょう。

生ポインタ（Raw Pointers）の時代と問題点

C言語から引き継がれた生ポインタ（*）は、究極の自由を提供しますが、同時に以下のような深刻なバグの温床となります。

メモリリーク（Memory Leak）: newしたメモリをdeleteし忘れる。
Dangling Pointer（ダングリングポインタ）: メモリ解放後（delete後）のポインタにアクセスする。
Double Free（二重解放）: 同じメモリ領域を2回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`

所有権が単一であることを表現するポインタです。スコープを抜けると自動的にメモリが解放されます。コピーはできず、所有権の「移動（ムーブ）」のみが可能です（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の所有権システムは、以下の3つの極めてシンプルなルールに基づいています。

Rustの個々の値は、所有者（owner）と呼ばれる変数を持つ。
いかなる時も所有者は一つである。
所有者がスコープから外れたら、値は破棄される。

Rustではデフォルトでリソースは「ムーブ」されます。C++のようにstd::moveを明示しなくても、代入操作によって所有権が移動します。

1
2
3
4
5
6
7
8


// Rust: 所有権の移動（ムーブ）
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 "Variable s1" participant Heap as "Heap Memory ('hello')" participant S2 as "Variable s2" S1->>Heap: "Allocates & Owns" Note over S1,S2: "let s2 = s1;" S1--xHeap: "Loses Ownership (Invalidated)" S2->>Heap: "Takes Ownership"

4. 借用（Borrowing）と参照

所有権を常に移動させていると、関数に値を渡すたびに所有権を返しもらわなければならず、非常に不便です。そこで登場するのが「借用（Borrowing）」です。C++のポインタや参照に相当します。

Rustにおける借用には2つの種類があります。

不変参照（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）をコンパイル時に完全に排除します。データ競合は、①2つ以上のポインタが同じデータに同時アクセスし、②少なくとも1つが書き込みを行い、③同期メカニズムがない場合に発生します。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）の防止

ボローチェッカーの威力が最も発揮される具体的な例として、「イテレータ無効化」という古典的なバグを見てみましょう。

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++: イテレータ無効化のバグ
#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やイテレータ無効化といった致命的なバグがコンパイル時に確実に捕捉されます。

graph LR A["Variable v (Owner)"] --> B["Heap Array [1, 2, 3]"] C["Reference 'first' (&v[0])"] -.->|"Immutable Borrow"| B A -->|X "Mutable Borrow Denied!"| D["v.push(4)"] style C stroke:#00FF00,stroke-width:2px style D stroke:#FF0000,stroke-width:2px

6. Rustにおける共有所有権：`Rc` と `Arc`

C++のstd::shared_ptrに相当する共有所有権もRustには用意されていますが、シングルスレッド用とマルチスレッド用に明確に型が分かれています。

シングルスレッド用：`Rc<T>` (Reference Counted)

Rc<T>は、非スレッドセーフな参照カウントスマートポインタです。アトミックな命令を使わずにカウントを増減させるため、単一スレッド内では非常に高速です。しかし、これを別スレッドに送ろうとすると、コンパイルエラーになります（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によるモダン化の波（スマートポインタ、ラムダ式、autoの導入）、そしてC++14/17/20と続く仕様の巨大化に並走しながらコードを書き続けてきました。

しかし近年、C++が抱える構造的な課題—特に「メモリ安全性の欠如」によるセキュリティ脆弱性（CVEの約7割がメモリ起因と言われています）と、「果てしなく複雑化する仕様と未定義動作（UB）」—に対する解決策として、Rustが劇的な台頭を見せています。Linuxカーネルへの公式採用や、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++のスマートポインタとムーブセマンティクスには、コンパイラによる静的な検証が不完全であるという致命的な弱点があります。

 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++");

 // 所有権を関数に移動（ムーブ）する
 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 applied"] B --> C["Ownership Transferred"] C --> D["Old Pointer Still Accessible"] D --> E["Potential Undefined Behavior (UB)"] F["Rust Box / String"] --> G["Passed by Value (Move)"] G --> H["Ownership Transferred"] H --> I["Compiler Blocks Old Variable"] I --> J["Memory Safety Guaranteed"]

借用（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()を呼び出してガードオブジェクトを取得する必要があります。ロックを取得せずにデータに触ることは、文法的に不可能です。

 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には、並行処理の安全性を担保する2つのコアトレイトが存在します。

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++ Thread Safety"] --> B["Relies on Developer Memory"] B --> C["Mutex Decoupled from Data"] C --> D["High Risk of Silent Data Races"] E["Rust Thread Safety"] --> F["Send and Sync Traits"] F --> G["Mutex Owns the Data"] G --> H["Data Races Prevented at Compile Time"]

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）による動的ディスパッチ、またはテンプレートによる静的ディスパッチ（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++ Build Environment"] --> B["CMakeLists.txt"] B --> C["vcpkg / Conan Integration"] C --> D["Generate Makefiles / Ninja"] D --> E["Compiler (GCC/Clang/MSVC)"] F["Rust Build Environment"] --> G["Cargo.toml"] G --> H["Fetch dependencies from crates.io"] H --> I["rustc (Cargo build)"] I --> J["Ready to run Binary"]

Cargo.toml に依存ライブラリ（クレート）の名前とバージョンを1行追記するだけで、推移的依存関係の解決、ダウンロード、ビルドまでを全自動で行ってくれます。さらに、テスト（cargo test）、ドキュメント生成（cargo doc）、静的解析（cargo clippy）、フォーマッタ（cargo fmt）など、開発に必要なツールチェーンが全てこのコマンド一つに統合されています。この快適さは、一度味わうとC++のビルド環境には戻りたくなくなるほどの破壊力を持っています。

7. Rustを学ぶ上でのデメリットと学習曲線

ここまでRustの長所を語りましたが、C++エンジニアがRustを実戦投入するにあたって直面する「壁」やデメリットも確実に存在します。

1. 苛烈なボローチェッカーとの格闘

C++で「何となく生のポインタで繋いでいた」データ構造（例えば双方向リンクリストや、グラフ構造、自己参照構造体など）をRustでそのまま実装しようとすると、所有権とライフタイムの制約によりコンパイルが通りません。ボローチェッカーを満足させるためには、Rc<RefCell<T>> のような複雑なラップを行うか、アリーナアロケータやインデックスベースの管理に設計を根本から見直す必要があります。

2. コンパイル時間の長さ

C++もテンプレートのネストによってコンパイルが遅くなりますが、Rustのコンパイル時間（特にゼロからのクリーンビルド）も決して短くありません。LLVMの強力な最適化パス、マクロの展開、ジェネリクスの単相化（モノモルフィゼーション）が重なるため、大規模プロジェクトではビルド時間がボトルネックになります。開発中は cargo check を多用するなどの工夫が必須です。

3. C++コードベースとの相互運用性

C言語（FFI）との連携は非常にスムーズですが、既存の巨大なC++コードベース（クラス、テンプレート、仮想関数を多用しているもの）とRustを直接連携させるのは非常に困難です。近年は cxx や autocxx といったブリッジツールが進化していますが、完全なシームレスな移行にはまだ高いハードルがあります。

まとめ：私たちはRustへ移行すべきか？

C++は今後もゲームエンジン開発や、既存の巨大なインフラストラクチャにおいて重要な役割を担い続けるでしょう。C++20/23による近代化も目覚ましく、より安全に書けるようになってきています。

しかし、「新規に立ち上げるシステムプログラミングのプロジェクト」において、私はもはやRustを選択しない理由を見つける方が難しいと感じています。コンパイルさえ通れば、未定義動作やメモリ破壊の恐怖から解放され、高いパフォーマンスで安全に並行処理を行えるという Rust の「確実性」は、エンジニアのメンタルモデルを劇的に改善します。

C++エンジニアにとって、Rustの学習は単に新しいシンタックスを覚えることではなく、「メモリとスレッドの安全な管理方法」に対する新たな視座を得る最高の体験です。ぜひ皆さんも、Cargoの快適さとボローチェッカーの厳しさを体感してみてください。