これshared_ptrが tr1 にありますstd::auto_ptr。両方とも異なるユース ケースがありますが、 のすべてのユース ケースはauto_ptrでも解決できますshared_ptr。auto_ptr特定の時点で 1 つのクラスのみが所有権を持っていることを明示的に表現したい場合に、それを放棄するか、それとも使用し続けますか?
私auto_ptrの見解では、コードの設計のニュアンスと指示を正確に追加することで、コードを明確にすることができますが、一方で、新しいプログラマーをトレーニングするときにさらに別の微妙な問題が追加されます。彼らはスマートポインターを理解する必要があり、それらがどのように機能するかの詳細。どこでもスマート ポインターを 1 つだけ使用する場合は、「すべてのポインターを にラップする」というルールを設定するだけで済みますshared_ptr。
これについてどう思いますか？
auto_ptr は署名にも適しています。関数がauto_ptr<T>by 値を取る場合、それは を消費することを意味しますT。関数が を返す場合、auto_ptr<T>所有権を放棄していることは明らかです。これにより、生涯に関する意図を伝えることができます。
一方、 usingscoped_ptr<T>は、 の有効期間を気にしたくないことを意味しますT。これは、より多くの場所で使用できることも意味します。どちらのスマート ポインターも有効な選択肢であり、1 つのプログラムで両方を使用できます。
std::auto_ptr「回避」陣営 にもう少し弾薬を提供するために:auto_ptrは次の標準 (C++0x) で廃止されます。これだけでも、他の何かを使用するための議論の十分な弾薬になると思います.
ただし、Konrad Rudolphが述べたように、 のデフォルトの代替auto_ptrはおそらくboost::scoped_ptr. moreのセマンティクスは のセマンティクスとscoped_ptrほぼ一致auto_ptrしており、同様の用途を意図しています。次の C++09 標準には、unique_ptr と呼ばれる同様のものがあります。
ただし、使用する必要があるshared_ptr場所を使用してscoped_ptrも何も壊れることはありません。オブジェクトが実際に共有されることがない場合、参照カウントを処理するために非常にわずかな非効率性が追加されるだけです。したがって、別のオブジェクトに渡されることのないプライベート メンバー ポインターの場合は、 を使用しますscoped_ptr。ポインターが別のものに渡される場合 (これには、コンテナー内でのポインターの使用が含まれます。または、所有権を譲渡し、保持または共有したくない場合) - を使用しますshared_ptr。
「shared_ptrどこでも使用する」は適切なデフォルト ルールであり、スマート ポインターの責任ある使用について人々に教える良い出発点であることは間違いありません。ただし、常に最適な選択とは限りません。
共有所有権が必要ない場合shared_ptrは、やり過ぎです。参照カウント用に別のメモリ ブロックを割り当てる必要があり、パフォーマンスに影響を与える可能性があり、ドキュメントの観点からはあまり明確ではありません。
個人的には、私は十分std::auto_ptrな多くの場所で使用しboost::scoped_ptrます。たとえば、介在する操作がスローされる可能性がある場所で、所有権が他の場所に転送される前にヒープ割り当てオブジェクトを保持します。
C++0x は、より良い代替手段としてstd::unique_ptr補完する必要があります。それが広く利用可能になったら、私はそれを使い始めます。std::shared_ptrstd::auto_ptr
Boost の使用を気にしない場合は、要件をより適切に満たしていない限り、 std::auto_ptrbyのすべての使用を置き換えることがベスト プラクティスだと思います。一方で、TR1 に含まれていないのは意図的なものだったに違いありません。boost::scoped_ptrstd::tr1::shared_ptrscoped_ptr
shared_ptr「すべてのポインターをラップする」が実際にデフォルトのモードであるべきであり、初心者のコーダーに与える適切なアドバイスであると私は信じています。ただし、あなたが言及した特別な所有権のケースでauto_ptrは、実際にはより適切であり、そのような状況ではその使用が奨励されるべきです.