導入: なぜ unique_ptr のコピー禁止が重要なのか
C++のメモリ管理において、std::unique_ptr は最も基本的かつ強力なスマートポインタです。しかし、使い始めたばかりのエンジニアがよく直面するのが「コピーしようとするとコンパイルエラーになる」という壁です。本記事では、なぜ std::unique_ptr がコピーを禁止しているのか、その設計思想と、実務でどのように扱うべきかを解説します。この仕組みを理解することで、メモリリークや二重解放（Double Free）といったバグを未然に防ぐ堅牢なコードが書けるようになります。
基礎知識: 所有権（Ownership）の概念
C++の動的メモリ管理において、最も避けるべきは「誰がこのメモリを解放すべきか不明確な状態」です。std::unique_ptr は、その名の通り「唯一の所有者」を前提としています。
もしコピーを許可してしまうと、2つのオブジェクトが同じメモリ領域を指し示し、どちらのデストラクタが先に呼ばれても、もう片方は不正なメモリを指す（ダングリングポインタ）危険が生じます。これを言語仕様レベルで防ぐために、std::unique_ptr はコピーコンストラクタと代入演算子が明示的に削除されています。
実装/解決策: 所有権の「移動」を利用する
コピーができない代わりに、std::unique_ptr は「所有権の移動（Move）」をサポートしています。std::move を使うことで、あるポインタから別のポインタへ、メモリの管理責任を完全に移譲することができます。
サンプルプログラム: コピー禁止の確認と移動の作法
以下のコードでは、コピーが失敗するケースと、std::move を用いて正しく所有権を移譲するケースを示します。
include <iostream>
include <memory>
include <utility>
struct Resource {
Resource() { std::cout << "リソース確保" << std::endl; }
~Resource() { std::cout << "リソース解放" << std::endl; }
};
int main() {
// 1. unique_ptr の作成
std::unique_ptr<Resource> ptr1 = std::make_unique<Resource>();
// 2. コピーを試みる（これはコンパイルエラーになります）
// std::unique_ptr<Resource> ptr2 = ptr1; // エラー: 削除された関数を呼び出そうとしています
// 3. 所有権の移動（Move）
// ptr1 が持っていた所有権を ptr2 に完全に移す
std::unique_ptr<Resource> ptr2 = std::move(ptr1);
// この時点で ptr1 は nullptr になっている
if (!ptr1) {
std::cout << "ptr1 は空になりました" << std::endl;
}
return 0; // ここで ptr2 がスコープを抜け、リソースが自動解放される
}
応用・注意点: 実務での落とし穴
実務で特に注意すべきは、関数引数として渡す際です。unique_ptr を関数に渡す場合、コピーしようとするとエラーになるため、以下のいずれかの方法をとります。
1. ポインタや参照を渡す: 関数内で所有権を奪う必要がないなら、ptr.get() で raw ポインタを渡すか、引数を Resource& とします。
2. std::move で所有権を渡す: 関数側でそのリソースを保持し続ける必要がある場合は、std::move を使って明示的に所有権を関数へ移譲します。
「コピーできない」という制限は、不便なルールではなく、「誰がいつリソースを解放するか」をプログラマに意識させるための安全装置です。この設計を理解すれば、複雑なオブジェクトのライフサイクル管理も自信を持って実装できるようになるはずです。
コメント