質問は少し基本的なように思えるかもしれませんが、パフォーマンス以外のスマート ポインターの欠点は何ですか? また、パフォーマンスが重要でないコードには常にそれらを使用する必要がありますか?
編集: Visual Studio 2013 RC と C++11 を使用しています
質問は少し基本的なように思えるかもしれませんが、パフォーマンス以外のスマート ポインターの欠点は何ですか? また、パフォーマンスが重要でないコードには常にそれらを使用する必要がありますか?
編集: Visual Studio 2013 RC と C++11 を使用しています
「スマート」ポインターはそれほどスマートではないかもしれませんが、たとえば、std::unique_ptr<T>
またはを使用する場合でも、リソースを保持するために常にスマートポインターを使用しstd::unique_ptr<T[]>
ます。ポインターを使用して非所有リンクをモデル化する場合、または非所有ポインターを渡す場合は、生のポインターを使用しています。これは、このジョブの正しい抽象化であり、オブジェクトの所有方法に関する選択に干渉しないためです。
たとえば a のunique_ptr
場合、適切な最適化コンパイラを使用してもパフォーマンスが低下することはほとんどありません。shared_ptr
余分なヒープ割り当てがある可能性があります。これは で解決でき、make_shared
参照カウントを維持するコストがありますが、独自の追跡または有効期間管理メカニズムを展開している場合は、この種のオーバーヘッドもかかる可能性があることを考慮してください。詳細については、 GotW #89を参照してください。
「常にそれらを使用すべきか」について、Sean Parent は、GoingNative 2013 のトークC++ Seasoningでこれ (およびいくつかの微妙な点) について説明しています。ある時点で、彼は shared_ptr-to-non-const がグローバル変数とほぼ同等であると述べています... これは見る価値があります。C++ Seasoningのスライドは利用可能ですが、それを見ることをお勧めします。
一般的に言えば、生のポインターにトレードオフがあるのと同様に、各スマート ポインターにはトレードオフがあります。状況とトレードオフを評価して選択するのはあなた次第です。そして、特に C++11 と C++14 の改良により、最近のほとんどではないにしても多くの状況に対応する十分に吟味されたスマート ポインターの亜種があるようです。