C++11は、不安全なstd::auto_ptrの代わりにstd::unique_ptrとstd::shared_ptrを導入しました。両者は、ファイルハンドルやデータベース接続のようなメモリ以外のリソースを管理するためにカスタムデリーターをサポートしています。しかし、所有権モデルとパフォーマンス要件によって、設計アプローチは根本的に異なります。
std::unique_ptrは独占的所有権を実装し、デリーターをその型の一部（第2のテンプレートパラメータ）として保存します。デリーターが状態を持つ場合、その状態は管理されたポインタとともにunique_ptrオブジェクト自体の中にスペースを占有します。std::shared_ptrは、制御ブロックをヒープに割り当てることで共有所有権を実装し、デリーターは型消去されてshared_ptrオブジェクトとは別に保存されます。
このアーキテクチャの違いは、明確なサイズ特性をもたらします。ステートレスデリーターを持つstd::unique_ptrは、Empty Base Optimizationのおかげで、通常のポインタとまったく同じスペースを占めます。対照的に、std::shared_ptrはデリーターのサイズや複雑さに関係なく、常に一定のサイズ（通常2つのポインタ）を維持します。なぜなら、デリーターは別に割り当てられた制御ブロックの中に存在するからです。
#include <memory> #include <cstdio> #include <iostream> struct FileDeleter { void operator()(FILE* fp) const { if (fp) std::fclose(fp); } }; struct StatefulDeleter { int flags = 0xDEAD; void operator()(FILE* fp) const { if (fp) std::fclose(fp); } }; int main() { // ステートレスデリーターを持つunique_ptr: サイズ == ポインタサイズ (64ビットでは8バイト) std::unique_ptr<FILE, FileDeleter> up(nullptr); // shared_ptr: デリーターに関係なく固定サイズ (16バイト) std::shared_ptr<FILE> sp(nullptr, FileDeleter{}); std::cout << "Unique (stateless): " << sizeof(up) << " bytes "; std::cout << "Shared (any deleter): " << sizeof(sp) << " bytes "; // ステートフルデリーターを持つunique_ptr: より大きなサイズ (16バイト: ポインタ + int + padding) std::unique_ptr<FILE, StatefulDeleter> up2(nullptr, StatefulDeleter{}); std::shared_ptr<FILE> sp2(nullptr, StatefulDeleter{}); std::cout << "Unique (stateful): " << sizeof(up2) << " bytes "; std::cout << "Shared (stateful): " << sizeof(sp2) << " bytes "; }
ある開発チームは、C APIから返されたレガシーデータベース接続ハンドル（void*）を管理する必要がありました。これらのハンドルはdb_disconnect()を介して特定のクリーンアップが必要であり、deleteではありませんでした。アプリケーションは、タイトなループ内で毎秒何千ものハンドルを生成し、メモリ使用量と割り当てパフォーマンスが重要でした。
最初に考慮されたアプローチは、ハンドルを保存し、デストラクタ内でdb_disconnect()を呼び出すカスタムRAIIラッパークラスConnectionGuardでした。利点はインターフェースに対する完全な制御と、接続特有のメソッドを追加できることでした。デメリットは、すべてのリソースタイプに対してかなりのボイラープレートコードが必要で、ポインタのセマンティクスを再発明する必要があり、スマートポインタ用に設計された標準ライブラリアルゴリズムとの互換性がなかったことです。
2つ目のソリューションは、db_disconnect()関数をキャプチャするラムダデリーターを使った**std::shared_ptr<void>**の利用です。利点は、標準コンポーネントを用いて即座に利用でき、必要に応じて所有権を共有する未来の安全性があることです。デメリットは、制御ブロックのための必須のヒープ割り当て、高頻度のユニークな所有権に不向きな原子的参照カウントのオーバーヘッド、ハンドルの軽量性に関係なく16バイトの固定オブジェクトサイズです。
3つ目のアプローチは、std::unique_ptr<void, decltype(&db_disconnect)>を関数ポインタデリーターまたは好ましくはステートレスファンクタで使用しました。利点は、ステートレスファンクタを使用する際にオーバーヘッドがゼロであること（ポインタのサイズ8バイトと一致）、ヒープ割り当てなし、排他所有権のセマンティクスを完璧に表現できることです。デメリットは、型シグネチャの冗長性とランタイムでデリーターを変更できないことです。
チームは、ステートレスファンクタデリーターを使用した3番目のソリューションを選択しました。この選択により、ヒープ割り当てが完全に排除され、ラッパーのサイズが8バイトに削減され、原子的操作のオーバーヘッドが除去され、自動クリーンアップが維持されました。
結果として、メモリ使用量が40％削減され、接続プーリングシステムの待ち時間が大幅に改善され、パフォーマンスを損なうことなく例外安全性が達成されました。
なぜstd::unique_ptrはデフォルトデリーターを使用する際に破棄時に完全な型を必要とするのに対し、std::shared_ptrはそうでないのか？
回答: std::unique_ptrはデフォルトデリーターで管理ポインタにdeleteを呼び出すため、**C++**標準では、Tへdeleteを呼び出すにはTが完全な型として定義されている必要があります。unique_ptrのデストラクタがTが前方宣言された状態でインスタンス化されると、コンパイルが失敗します。std::shared_ptrは、制御ブロック内でデリーター（Tを破壊する方法を知っている）を構築時にキャプチャします。デリーターは型消去されて別に保存されるため、shared_ptrは後でTが不完全な状態で破棄されることができます。この区別は、Pimpl（Implementationへのポインタ）イディオムにとって重要です: shared_ptrは実装の詳細をソースファイルに隠すことを可能にする一方で、unique_ptrは完全な型または実装が見えるところで定義された明示的なカスタムデリーターを要求します。
なぜstd::make_uniqueはカスタムデリーターをサポートせず、推奨される代替手段は何ですか？
回答: std::make_unique（C++14で導入）は例外安全な割り当てを提供しますが、std::unique_ptr<T>またはstd::unique_ptr<T[]>のみを返し、std::default_deleteを使用します。この関数は、デリーターの型がunique_ptrテンプレートシグネチャの一部でなければならないため、引数からデリーターの型を推測することができません。また、ファクトリ関数は明示的なテンプレートパラメータなしでカスタムデリーター型を暗黙に推測できません。推奨される代替手段は、直接コンストラクションです:std::unique_ptr<T, CustomDeleter>(new T(args), CustomDeleter{...})。このアプローチは、デリーター型をテンプレート内で明示的に指定し、カスタムリソースクリーンアップロジックを許可しますが、例外安全性の保証を維持するために手動の例外処理または注意深い構築順序が必要です。
Empty Base Optimizationは、ステートレスデリーターを使用する際のstd::unique_ptrメモリレイアウトにどのように影響し、なぜstd::shared_ptrには適用できないのか？
回答: std::unique_ptrは、デリーターがクラス型である場合、そのデリータークラスから派生します。デリーターにデータメンバーが含まれていない（ステートレス）場合、C++はEmpty Base Optimization (EBO)を適用し、空のベースサブオブジェクトが0バイトを占有できるようにします。その結果、sizeof(std::unique_ptr<T, StatelessDeleter>)はsizeof(T*)と等しくなり、ゼロオーバーヘッドの抽象化を実現します。std::shared_ptrは、型消去をサポートする必要があるため、EBOを利用できません。同じTのshared_ptrは、デリーターに関係なく同じサイズを持つ必要があるため、shared_ptrはデリーターをshared_ptrオブジェクト自体の中ではなく、ヒープに割り当てられた制御ブロックに保存します。この設計は、デリーターのランタイムポリモーフィズムを可能にしますが、ヒープ割り当てを強いる一方で、unique_ptrが享受するスタック領域の最適化を妨げます。