web-dev-qa-db-ja.com

shared_ptrとscoped_ptr

scoped_ptrはコピーできないため、範囲外で削除されます。したがって、これは制限付きのshared_ptrです。したがって、コピー操作を実際に制限する必要がある場合を除いて、shared_ptrを使用することをお勧めします。オブジェクトのコピーを作成する必要があるかどうかわからない場合があるためです。したがって、問題は次のとおりです。上記のケース以外に、shared_ptrの代わりにscoped_ptrを使用することをお勧めします(または推奨します)。 scoped_ptrshared_ptrよりはるかに高速に動作しますか、それとも何か利点がありますか?

ありがとう!

37
Narek

shared_ptrscoped_ptrよりも重いです。参照カウントオブジェクトと管理オブジェクトを割り当てて解放し、スレッドセーフな参照カウントを処理する必要があります。私が作業した1つのプラットフォームでは、これは大きなオーバーヘッドでした。

(一般的に)私のアドバイスは、ニーズを満たす最も単純なオブジェクトを使用することです。参照カウントによる共有が必要な場合は、shared_ptrを使用してください。単一の参照で終了した後で自動削除が必要な場合は、scoped_ptrを使用します。

70
Mike Seymour

パフォーマンス-shared_ptrにはより多くの機能がありますが、追加の割り当ても必要です(これも大きくなりますが、ほとんど問題になりません)。

[編集] 2番目の割り当てはmake_sharedを使用することで回避できますが、weak_ptrはオブジェクトが破棄された後でも割り当て全体を保持します。これは大きなオブジェクトでは問題になる場合があります。

意図の表現scoped_ptrを使用して、何をしたいかをより明確に述べます。 (ご参考までに-それは良いことです:))これを正しく行うと、shared_ptrは「このオブジェクトはこのスコープを超えて存続することを意図している」とも示します

16
peterchen

それらの意図された目的は異なるため、多くの場合、「shared_ptr vs scoped_ptr」はまったく問題ではありません。もちろん、必要なのがscoped_ptrだけの場合は、shared_ptrを使用できます。しかし、ポイントは何ですか? shared_ptrは、すべての参照カウントが含まれるため、オーバーヘッドが若干大きくなる可能性があります。

6
sellibitze

scoped_ptrshared_ptr。それはそうです。 shared_ptr常に、アロケータまたはデフォルトのアロケータを使用してメモリを割り当てます。

3
Alexey Malistov

Scoped_ptrは、「参照カウント」の非常に特殊なケースのみを実行するため、shared_ptr、weak_ptr、unique_ptrとほとんど共通点がありません。適切に設計されたコードで頻繁に必要になるものではありませんが、利用できる優れたツールです。

基本的に、scoped_ptrは参照カウント対象ではありません。むしろ、これはスタック上(ローカルスコープ内)に作成するオブジェクトなので、次のようなことができます。

  //Some enclosing scope- anything set off by "{}" or even a function:
   {
       scoped_ptr<MyObject> ptr = new MyObject( parameters...);
   } // When we hit this closing brace, "ptr" will delete the "MyObject" inside.

ミューテックスやその他の同期プリミティブでは、このパターンがよく見られる傾向があります。「AutoLock」を宣言して、渡されたミューテックスをロックし、削除時にロックを解除して「{}」スコープ全体をクリティカルセクションに変えることができます。

また、 'scoped_ptr'は、何らかの理由で "MyObject obj(params ..)"のような単純な古いスタック割り当てを実行できない場合にのみ意味があることに注意してください。結局のところ、それは、ヒープに割り当てられたオブジェクトをスタック上のオブジェクトのように使用できるようにすることです。これは、shared_ptrとその従属の参照カウントよりもユースケースがはるかにまれである傾向があります。

1
Zack Yezek