**C++ の所有権システムの理解** C++ はオブジェクトがどのように作成・使用・破棄されるかを決定する「所有権モデル」に依存しています。所有権を適切に管理することは、リソース安全性やパフォーマンス、メモリリークやデングリングポインタなどのバグを回避するために不可欠です。 --- ### 1. 基本概念 | 概念 | 定義 | |------|------| | **リソース** | 解放が必要なもの（メモリ、ファイルハンドル、ソケット等）。 | | **所有権** | リソースを不要になったときに解放する責任。 | | **スコープ** | オブジェクトが存在する期間の範囲。 | --- ### 2. 所有権パターン - **自動ストレージ（スタック）** - オブジェクトはスタック上で作成される。 - スコープを抜けたときに自動的に破棄される。 - 高速で手動解放不要。 - **動的割り当て（ヒープ）** - `new`/`delete` や生ポインタを使用。 - 呼び出し側が明示的にメモリを解放する必要がある。 - 適切に管理されないとリークやデングリングポインタの危険がある。 - **スマートポインタ**（C++11以降） - **`std::unique_ptr<T>`** - 単一所有者、コピー不可。 - 移動セマンティクスで所有権を移譲。 - **`std::shared_ptr<T>`** - 参照カウントによる共有所有。 - C++17以降はスレッド安全な参照カウント。 - **`std::weak_ptr<T>`** - `shared_ptr` の非所有オブザーバー。 - 循環参照を打破する。 - **リソース取得＝初期化（RAII）** - コンストラクタでリソース取得をカプセル化。 - デストラクタで解放。 - 例外が投げられた場合でもクリーンアップを保証。 --- ### 3. ベストプラクティス 1. **可能な限り自動ストレージを優先**：手動クリーニング不要。 2. **動的リソースにはスマートポインタを使用** - 排他所有なら `unique_ptr`。 - 真の共有所有が必要なときだけ `shared_ptr` を使う。 3. **公開インターフェイスで生ポインタは非所有の場合に限定し、意図を文書化**。 4. **リソース管理クラスにはムーブセマンティクスを実装**：コピーコストを抑える。 5. **循環参照が起きそうな場合は `weak_ptr` を活用**。 6. **「Rule of Five」を遵守**：デストラクタ、コピー/ムーブコンストラクタ・代入演算子を必要に応じて実装。 --- ### 4. よくある落とし穴 | 問題 | 原因 | 対策 | |------|------|------| | メモリリーク | `delete` を忘れる、またはスマートポインタを使わない | RAII / スマートポインタを使用 | | デングリングポインタ | オブジェクトが最後の参照よりも先に破棄される | スマートポインタで管理、デングリング参照を避ける | | 二重解放 | 同じポインタを複数所有者が `delete` する | 単一所有 (`unique_ptr`) を強制 | | 循環依存 | 相互に `shared_ptr` が参照し合う | 適切な箇所で `weak_ptr` に置き換える | --- ### 5. 要約 C++ の所有権システムは、リソースがいつ割り当てられ、いつ解放されるかを制御するためのルールとツールのセットです。自動ストレージ、RAII、およびスマートポインタを活用すれば、安全で効率的、かつ保守性の高いコードを書くことができます。

投稿日：2026‑01‑19

私は最近職場で C++ を使い始め、再度学び直すことにしました。理解した内容を書き留めるのは、あるテーマを習得する最も効果的な方法です。C++ では「オブジェクト所有モデル」が難しく感じられますが、それは一つの概念ではなく、小さな複数の概念の集合です。「所有」と言うときは、オブジェクトの生成・破棄、参照を渡すこと、およびオブジェクトの所有権を移転することを指します。これらを網羅した単一のガイドは存在しません。

この概念は現代 C++（C++11 以降が「現代」とみなされるかどうかは疑問）を書く上でも読む上でも非常に重要です。たとえ C でクラス風の構造を書きたいだけなら、

std::vector

のような標準コンテナを使うことになるでしょう。これには RAII、参照、およびムーブセマンティクスなど所有権関連の機能への理解が不可欠です。それらを知らずにコードを書くと、未定義動作で満ちたバグの多いプログラムや、不要なコピーによる非効率的な実装になってしまいます。

以下は私の C++ 所有モデルに関する理解です。C++ を基本レベルまで学んだ人がさらに深く知りたいとき、または既に熟知しているものの概念・用語を正式に学んでいない場合に役立つと思います。

---

1. 誰がオブジェクトを所有するか？

C++ ではすべてのオブジェクトには、そのデータを使用しなくなった時点でクリーンアップを担当する「所有者」が存在します。ガベージコレクション付き言語から来た場合、この所有概念は奇妙に感じられるでしょう。以下のコードを見てください。

char* get_name(File* file);

関数はファイル名を C スタイル文字列として返しますが、返された文字列を解放する責任は誰にありますか？考えられるケースは二つです：

1. 関数側で新しいメモリを確保 – 呼び出し側は不要になった時点で解放すべきです。

2. file

   が名前を保持するプロパティを持つ – 関数はそのアドレスだけを返し、呼び出し側が解放してはなりません。

どちらのケースかによって呼び出し側の振る舞いが変わります。ガベージコレクション付き言語ではすべての変数が実質的に「借用者」であり GC が所有者です。一方 C++ では所有権を明示する必要があります。

---

2. オブジェクトの生成と破棄

オブジェクトを保持する変数を宣言すると、オブジェクトは生成され、その変数が所有者になります。オブジェクトにデストラクタ（リソース解放を行う特殊関数）がある場合、ブロックが終了した時点で自動的に呼び出されます。この「資源を変数に結びつける」パターンは RAII（Resource Acquisition Is Initialization）と呼ばれます。オブジェクトが存在する期間を 寿命 と言います。

例：手動メモリ管理

void foo(std::size_t buffer_size) {
    char* buffer = new char[buffer_size];
    int result = 0;
    try {
        while (has_more) {
            read(buffer);
            result += process(buffer);
        }
    } catch (std::exception& e) {
        delete[] buffer;
        throw;
    }
    delete[] buffer;
    return result;
}

delete

の呼び出しはエラーが発生しやすく、例外が投げられた場合のクリーンアップを手動で行う必要があります。

例：RAII と

unique_ptr

void foo(std::size_t buffer_size) {
    std::unique_ptr<char[]> buffer = std::make_unique<char[]>(buffer_size);
    int result = 0;
    while (has_more) {
        read(buffer.get());
        result += process(buffer.get());
    }
    // `buffer` はここで自動的に解放される
    return result;
}

明示的な

delete

は不要です。

unique_ptr

のデストラクタがスコープを抜けた時点でメモリを開放します。例外が投げられても安全です。

---

3. デストラクタ

デストラクタ（

~ClassName()

）はオブジェクトの寿命が終了したときに実行されます。この中で、コンストラクタで確保されたすべてのリソースを解放する必要があります。もしクラスがコンストラクタでメモリを確保し、デストラクタで何もしていなければメモリリークになります。

class RAIIMutex {
    std::mutex& mutex;
public:
    explicit RAIIMutex(std::mutex& m) : mutex{m} { mutex.lock(); }
    ~RAIIMutex() { mutex.unlock(); }
};

使用例：

std::mutex global_mutex;
void foo() {
    RAIIMutex guard(global_mutex);
    // 保護されたリソースを安全に利用
}

guard

がスコープから外れると、デストラクタが自動的にミューテックスのアンロックを行います。

---

4. 寿命（Lifetime）

オブジェクトおよび参照には「寿命」があります。これは利用可能になる開始時点と、もう使用できなくなる終了時点から構成されます。ローカル変数は宣言時に寿命を開始し、ブロックの終わりで終了します。静的変数には別の規則がありますが、本稿では省略します。

オブジェクトが寿命の終わりに達すると、そのリソースは他のオブジェクトで再利用できるようになります。これがムーブセマンティクスの基盤です。

---

5. 参照とポインタ

変数をコピーせずに別関数へ渡すには、参照（またはポインタ）を使用します。参照は参照先オブジェクトより長く生存してはなりません。

size_t bar(const std::vector<int>& vec) {
    size_t result = 0;
    for (auto i : vec) { /* i を使う */ }
    return result; // `vec` は関数内でのみ使用されるため安全
}

しかし、参照をその所有者より長く保持すると危険です。

class B {
    std::vector<int>& vec;
public:
    void set_vec(std::vector<int>& v) { vec = v; }
    size_t bar() const {
        size_t result = 0;
        for (auto i : vec) { /* i を使う */ }
        return result;
    }
};

int main() {
    B b;
    if (some_condition) {
        std::vector<int> vec{1,2,3};
        b.set_vec(vec); // `vec` はブロック終了時に破棄される
    }
    b.bar(); // ダングリング参照！
}

常に参照が指すオブジェクトの寿命が十分長いことを確認してください。

---

6. ムーブセマンティクス

C++11以前はコピーまたはポインタしか使えませんでした。ムーブセマンティクスは、破棄される直前のオブジェクトからリソースを「奪取」し、不要なコピーを回避します。例えば

std::vector

が増大するとき、要素をコピーではなくムーブできます。

for (size_t i = 0; i < size_; ++i) {
    new_buffer[i] = std::move(buffer_[i]); // コピーの代わりにムーブ
}

std::move

は何か？

template<class T>
typename std::remove_reference<T>::type&& move(T& t) {
    return static_cast<typename std::remove_reference<T>::type&&>(t);
}

これは単に左辺値参照を右辺値参照へキャストします。右辺値参照は「オブジェクトが間もなく失効する」ことを示すので、オーバーロードで所有権移転を利用できます。

例として

std::string

は次のように定義されています：

std::string(const std::string&);   // コピーコンストラクタ
std::string(std::string&&);        // ムーブコンストラクタ

左辺値を渡すとコピーコンストラクタが選択され、

std::move

を適用するとムーブコンストラクタが呼び出されます。

---

7. 結論

長文でした。読んでいただきありがとうございます！これで C++ の所有システムに対する理解が深まったことを願います。見た目は無関係に思える機能が集まり、まとまりのあるモデルを構築しています。さらに多くの詳細がありますが、実際のコードではここで紹介した基本概念だけでも十分です。

---

8. 参考文献

• Move from Scratch
• C++ の値カテゴリに関する動画
• RAII – cppreference.com
• unique_ptr – cppreference.com
• Storage class specifiers – c language