これは ガベージコレクションスレッド から派生したもので、単純な答えが特定のスマートポインターの実装に関する多くのコメントを生成すると考えたため、新しい投稿を開始する価値がありました。
最終的に問題となるのは、C++のスマートポインターのさまざまな実装と、それらをどのように比較するかです。単純な長所と短所、または例外があり、そうでなければうまくいくはずだと思うかもしれないものに対する落とし穴です。
私はいくつかの実装を投稿しましたが、少なくとも以下の回答として使用し、少なくともその違いと100%正確ではない可能性のある相違点の理解として使用することを検討したため、必要に応じて事実を確認または修正してください。
目標は、いくつかの新しいオブジェクトとライブラリについて学習するか、すでに広く使用されている既存の実装の使用と理解を修正し、他の適切な参照を得ることです。
ポリシーベースのスマートポインターを実装する Loki もあります。
ポリシーベースのスマートポインターに関するその他の参照。多くのコンパイラーによる多重継承に加えて、空のベース最適化の不十分なサポートの問題に対処しています。
与えられたものに加えて、いくつかの安全指向のものもあります:
mse::TRefCountingPointer
は、std::shared_ptr
のようなスマートポインターをカウントする参照です。違いは、mse::TRefCountingPointer
はより安全で、小さく、高速ですが、スレッドセーフメカニズムがありません。そして、それは、常に有効に割り当てられたオブジェクトを指していると安全に想定できる「ヌルではない」バージョンと「修正済み」(リターゲッタブルでない)バージョンがあります。したがって、基本的に、ターゲットオブジェクトが非同期スレッド間で共有される場合はstd::shared_ptr
を使用し、そうでない場合はmse::TRefCountingPointer
がより最適です。
mse::TScopeOwnerPointer
はboost::scoped_ptr
に似ていますが、mse::TScopeFixedPointer
やstd::shared_ptr
のような「強力な」ポインター関係でstd::weak_ptr
と連動します。
mse::TScopeFixedPointer
は、スタックに割り当てられているオブジェクト、またはその「所有」ポインターがスタックに割り当てられているオブジェクトを指します。ランタイムコストなしでコンパイル時の安全性を強化するために、その機能が(意図的に)制限されています。 「スコープ」ポインターのポイントは、基本的に、(実行時の)安全メカニズムが必要ないほど単純で決定的な状況のセットを識別することです。
mse::TRegisteredPointer
は、ターゲットオブジェクトが破棄されるときにその値が自動的にnull_ptrに設定されることを除いて、生のポインターのように動作します。ほとんどの場合、生のポインターの一般的な代替として使用できます。生のポインタのように、本質的なスレッドセーフはありません。しかし、代わりに、スタックに割り当てられたオブジェクトをターゲットとする(および対応するパフォーマンスの利点を得る)問題はありません。実行時チェックが有効な場合、このポインターは無効なメモリにアクセスしても安全です。 mse::TRegisteredPointer
は有効なオブジェクトを指す場合、生のポインターと同じ動作をするため、コンパイル時のディレクティブで「無効化」(対応する生のポインターに自動的に置き換えられます)して、キャッチに役立てることができますデバッグ/テスト/ベータモードではバグが発生しますが、リリースモードではオーバーヘッドコストは発生しません。
ここ は、それらを使用する理由と使用方法を説明する記事です。 (注、恥知らずなプラグイン。)