閉じる

【C++】weak_ptrの使い方を徹底解説！循環参照の解決方法とshared_ptrとの違い

広告

C++におけるメモリ管理は、プログラムの安全性とパフォーマンスを左右する極めて重要な要素です。

かつては生のポインタによる手動管理が一般的でしたが、現代のC++(C++11以降)ではスマートポインタの使用が推奨されています。

その中でも、std::shared_ptrとセットで理解すべきなのがstd::weak_ptrです。

本記事では、初心者が陥りやすい「循環参照」の罠をどのように解決するのか、またshared_ptrとの具体的な違いや使い分けについて、現在の標準的なコーディングスタイルに基づき、豊富な図解とともに徹底的に解説します。

目次 [ close ]
  1. weak_ptrとは何か？
    1. なぜweak_ptrが必要なのか
  2. 循環参照の問題点と解決策
    1. shared_ptrによる循環参照の例
    2. weak_ptrによる解決
  3. weak_ptrの具体的な使い方
    1. 基本的なメソッド
    2. lock()メソッドによる安全なアクセス
  4. 内部構造とコントロールブロックの仕組み
    1. 2種類の参照カウンタ
    2. オブジェクト破棄とメモリ解放のタイミング
  5. shared_ptr と weak_ptr の比較
  6. 実践的な活用シーン
    1. キャッシュ機構の実装
    2. オブザーバーパターンの実装
  7. 注意点とベストプラクティス
  8. まとめ

weak_ptrとは何か？

std::weak_ptrは、一言で言えば「所有権を持たないスマートポインタ」です。

shared_ptrがオブジェクトの「所有者」として振る舞い、参照カウンタを増減させて寿命を管理するのに対し、weak_ptrはあくまで「観察者」としての役割に徹します。

weak_ptrは、shared_ptrが管理しているリソースを指し示しますが、そのリソースの参照カウンタ（shared count）を増加させません。

そのため、weak_ptrがどれだけ存在していても、すべてのshared_ptrが破棄されれば、対象のオブジェクトはメモリから解放されます。

なぜweak_ptrが必要なのか

もしshared_ptrしかなかった場合、特定の構造においてメモリが解放されなくなる深刻な問題が発生します。

それが循環参照です。

weak_ptrの存在意義の大部分は、この循環参照を打破し、メモリリークを防ぐことにあります。

また、オブジェクトが既に破棄されているかどうかを安全に確認できる仕組みを提供することも大きな役割です。

循環参照の問題点と解決策

スマートポインタを使用しているからといって、メモリリークから完全に解放されるわけではありません。

shared_ptr同士が互いを指し合ってしまうと、プログラムが終了するまで（あるいは永久に）メモリが解放されない事態に陥ります。

shared_ptrによる循環参照の例

以下のコードは、親クラスと子クラスが互いにshared_ptrで持ち合う、典型的な循環参照の例です。

C++
#include <iostream>
#include <memory>
#include <string>

// 子クラスの先行宣言
struct Child;

struct Parent {
    std::string name;
    std::shared_ptr<Child> child; // 子への所有権

    Parent(std::string n) : name(n) { std::cout << name << " が生成されました\n"; }
    ~Parent() { std::cout << name << " が破棄されました\n"; }
};

struct Child {
    std::string name;
    std::shared_ptr<Parent> parent; // 親への所有権（ここで循環が発生！）

    Child(std::string n) : name(n) { std::cout << name << " が生成されました\n"; }
    ~Child() { std::cout << name << " が破棄されました\n"; }
};

int main() {
    {
        auto p = std::make_shared<Parent>("親ポチ");
        auto c = std::make_shared<Child>("子ポチ");

        // 互いに参照し合う
        p->child = c;
        c->parent = p;

        std::cout << "スコープを抜けます...\n";
    }
    std::cout << "スコープを抜けました。\n";
    return 0;
}
実行結果
親ポチ が生成されました
子ポチ が生成されました
スコープを抜けます...
スコープを抜けました。

この実行結果を見ると、デストラクタ（破棄されました）が呼ばれていないことがわかります。

スコープを抜けて変数pとcが消滅しても、お互いがお互いの参照カウンタを保持し続けているため、カウントが0にならず、メモリ上に残り続けてしまうのです。

weak_ptrによる解決

この問題を解決するために、片方のポインタをweak_ptrに変更します。

一般的には、親子関係であれば「子から親への参照」をweak_ptrにします。

C++
#include <iostream>
#include <memory>
#include <string>

struct Child;

struct Parent {
    std::string name;
    std::shared_ptr<Child> child;

    Parent(std::string n) : name(n) { std::cout << name << " 生成\n"; }
    ~Parent() { std::cout << name << " 破棄\n"; }
};

struct Child {
    std::string name;
    // shared_ptr ではなく weak_ptr を使う
    std::weak_ptr<Parent> parent; 

    Child(std::string n) : name(n) { std::cout << name << " 生成\n"; }
    ~Child() { std::cout << name << " 破棄\n"; }
};

int main() {
    {
        auto p = std::make_shared<Parent>("Parent");
        auto c = std::make_shared<Child>("Child");

        p->child = c;
        c->parent = p; // weak_ptrに代入（参照カウンタは増えない）

        std::cout << "スコープを抜けます...\n";
    }
    std::cout << "スコープを抜けました。\n";
    return 0;
}
実行結果
Parent 生成
Child 生成
スコープを抜けます...
Parent 破棄
Child 破棄
スコープを抜けました。

今度は正しくデストラクタが呼ばれました。

ChildからParentへの参照がweak_ptrになったことで、pがスコープを抜けた際にParentの参照カウンタが0になり、正常に破棄が行われます。

その後、Parentが所有していたchild（shared_ptr）も破棄されるため、連鎖的にChildも解放されるという仕組みです。

weak_ptrの具体的な使い方

weak_ptrは直接オブジェクトのメンバにアクセスすることはできません。

なぜなら、アクセスしようとした瞬間にオブジェクトが既に破棄されている可能性があるからです。

そのため、「一時的にshared_ptrに変換する」という手順を踏む必要があります。

基本的なメソッド

weak_ptrを使いこなすために必須となる主なメソッドを紹介します。

メソッド名説明
lock()対象を指す shared_ptr を作成して返す。破棄済みなら空の shared_ptr を返す。
expired()オブジェクトが既に破棄されているかどうかを判定する（bool）。
use_count()リソースを共有している shared_ptr の数を取得する。
reset()保持している弱参照を解放する。

lock()メソッドによる安全なアクセス

weak_ptrで管理されているオブジェクトに触れるには、必ずlock()を使用します。

これにより、マルチスレッド環境などでも「アクセスしている最中にオブジェクトが消える」といった事故を防ぐことができます。

C++
#include <iostream>
#include <memory>

void check_and_print(std::weak_ptr<int> wp) {
    // lock()を呼び出してshared_ptrを取得
    if (auto sp = wp.lock()) {
        // オブジェクトが存在する場合
        std::cout << "値を取得しました: " << *sp << std::endl;
    } else {
        // オブジェクトが既に破棄されている場合
        std::cout << "オブジェクトは既に存在しません。" << std::endl;
    }
}

int main() {
    std::weak_ptr<int> wp;

    {
        auto sp = std::make_shared<int>(42);
        wp = sp;
        check_and_print(wp); // 有効な状態
    }

    // スコープを抜けたので、spが指していたメモリは解放されている
    check_and_print(wp); // 無効な状態

    return 0;
}
実行結果
値を取得しました: 42
オブジェクトは既に存在しません。

このように、lock()の戻り値をif文でチェックすることで、ダングリングポインタ（無効なメモリ領域を指すポインタ）によるクラッシュを回避できます。

内部構造とコントロールブロックの仕組み

weak_ptrがどのようにして「オブジェクトは消えているが、その状態は知っている」という器用な真似をできるのか、その裏側を解説します。

C++のスマートポインタ（shared_ptrとweak_ptr）は、実際のオブジェクトとは別に「コントロールブロック（管理オブジェクト）」をメモリ上に生成します。

2種類の参照カウンタ

コントロールブロックには、以下の2つのカウンタが格納されています。

Shared Count（参照数）

このオブジェクトを所有しているshared_ptrの数。

これが0になると、オブジェクト本体が破棄（デストラクタ呼び出し）されます。

Weak Count（弱参照数）

このオブジェクトを観察しているweak_ptr（および、コントロールブロック自体を参照しているshared_ptr）の数。

これが0になると、コントロールブロック自体がメモリから解放されます。

オブジェクト破棄とメモリ解放のタイミング

ここが重要なポイントですが、「オブジェクトの破棄」と「コントロールブロックの解放」はタイミングが異なる場合があります。

例えば、shared_ptrがすべて消えてShared Countが0になっても、まだweak_ptrが残っている場合、Weak Countは0になりません。

このとき、オブジェクトのデストラクタは呼ばれますが、コントロールブロックは残り続けます。

なぜなら、weak_ptrが「オブジェクトはもう消えたのか？」を確認するために、コントロールブロックの情報が必要だからです。

すべてのweak_ptrも消滅し、Weak Countが0になった瞬間に、ようやくコントロールブロックもメモリから完全に消去されます。

shared_ptr と weak_ptr の比較

両者の違いを明確にするために、表にまとめました。

特徴shared_ptrweak_ptr
所有権あり（共同所有）なし（観察のみ）
参照カウンタへの影響Shared Count を増やすWeak Count を増やす
メンバへのアクセス-> や * で直接可能lock() して shared_ptr に変換が必要
有効性の確認不要（常に有効なはず）expired() や lock() で確認必須
主な用途リソースの共有、生存期間の管理循環参照の回避、キャッシュ、オブザーバ

実践的な活用シーン

weak_ptrは、単に循環参照を避けるためだけの道具ではありません。

設計上のテクニックとして非常に強力な武器になります。

キャッシュ機構の実装

一度生成した重いデータをメモリ上にキャッシュしておきたいが、どこからも使われなくなったら自動的に消えてほしい、という場合に便利です。

キャッシュ側でshared_ptrを持ってしまうと、誰も使っていないのにキャッシュが所有権を握り続けてしまい、メモリが解放されません。

そこで、キャッシュには weak_ptr を格納するようにします。

  1. データを要求されたら、キャッシュ内の weak_ptr を lock() する。
  2. 成功すれば（まだ生きていれば）、その shared_ptr を返す。
  3. 失敗すれば（既に破棄されていれば）、新しく生成して、キャッシュを更新する。

オブザーバーパターンの実装

特定のイベントを通知する「被験者（Subject）」と、それを受け取る「観察者（Observer）」の関係でも活躍します。

被験者が観察者をshared_ptrでリスト管理してしまうと、観察者が不要になってもリストに含まれている限り破棄されません。

これをweak_ptrのリストにすることで、「観察者が存在している間だけ通知を送り、破棄されたら自動的に通知リストから実質的に除外する」という柔軟な設計が可能になります。

注意点とベストプラクティス

weak_ptrを使用する際に意識しておくべきポイントをいくつか挙げます。

生ポインタの代わりに使わない

「所有権を持たない」という点では生ポインタ（T*）と似ていますが、生ポインタはオブジェクトが破棄されたかどうかを知る術がありません（ダングリングポインタ問題）。

安全性が求められる現代的なC++では、生存確認が必要な非所有ポインタには必ずweak_ptrを検討しましょう。

lock() の戻り値は即座にチェックする

以下のようなコードは危険です。

C++
// 良くない例
if (!wp.expired()) {
    // expired()チェック後、lock()するまでの間に別スレッドで破棄される可能性がある
    auto sp = wp.lock(); 
    sp->do_something();
}

// 良い例
if (auto sp = wp.lock()) {
    // このスコープ内ではspによって生存が保証される
    sp->do_something();
}

マルチスレッド環境では、expired()でチェックした直後に他スレッドでオブジェクトが消える可能性があるため、一気に lock() して、その戻り値を確認するのが鉄則です。

まとめ

std::weak_ptrは、shared_ptrによる強力なメモリ管理を補完し、より安全で柔軟なプログラムを記述するための不可欠なツールです。

  • 循環参照によるメモリリークを防ぐための特効薬である。
  • 所有権を持たず、リソースの生存確認と一時的なアクセスを提供する。
  • アクセス時には必ず lock() を使用して shared_ptr に格上げする。
  • 内部的にはコントロールブロックの Weak Count を管理している。

これらの中核的な概念を理解することで、複雑なオブジェクト構造でもメモリリークを恐れずに設計できるようになります。

現代のC++開発において、shared_ptrとweak_ptrを正しく使い分けるスキルは、高品質なコードを書くための第一歩と言えるでしょう。

スマートポインタとRAII

クラウドSSLサイトシールは安心の証です。

URLをコピーしました！