私はいくつかのプロジェクトを使用しているboost::shared_ptrか、std::shared_ptr広範囲に使用しています（一方にこの質問に対する良い答えがあるが、もう一方にはない場合は、すぐにどちらかの実装に変換できます）。Boostの実装では、Boost.Assertを使用して、実行時operator*またはoperator->実行時に空（NULL）ポインターが検出された場合に戻らないようにします。一方、libc++の実装にはチェックが欠けているようです。
もちろん、shared_ptr使用する前にaの有効性を確認する必要がありますが、大規模な混合パラダイムコードベースを使用すると、例外をスローするバリエーションを試してみたいと思うようになります。ほとんどのコードは比較的例外を認識しており、セグメンテーション違反ではなく、せいぜい高レベルで再開可能な状態に失敗するためstd::terminate()です。
の堅牢性を維持しながら、これらのアクセサを最適にカスタマイズするにはどうすればよいshared_ptrですか？カプセル化shared_ptrするのthrowing_shared_ptrが最善の選択肢のようですが、私は魔法を破るのを警戒しています。Boostソースをコピーして、ASSERTsを適切なthrowステートメントに変更するのが最善ですか？
適切な型のためにどこでも使用される実際の型名smart_ptr<T>は、マクロから展開されたtypedefです。つまりForwardDeclarePtr(Class)、次のように展開されます。
class Class;
typedef boost::smart_ptr<Class> ClassPtr;
すべてが合格、取得、または保存されるClassPtrので、基になる型をかなり自由に置き換えることができます。これにより、潜在的なスライス/非表示の問題が軽減されると思います。