3

std :: tr1::shared_ptrまたはboost::shared_ptr（参照カウントメカニズムによる）の作成、割り当て、コピー、および破棄には、（場合によっては重大な）パフォーマンスの低下があることに気付きました。構築された後、shared_ptrでラップされたポインターにアクセスしても、パフォーマンスが低下しないというのは正しいですか？

言い換えれば：与えられた

std::tr1::shared_ptr<myClass> SharedA(new myClass);
myClass *NakedA = new myClass;

します

SharedA->someClassMember

と同じオーバーヘッドがあります

NakedA->someClassMember

？

4

2 に答える 2

9

デバッグサポートのない最適化されたビルドでは、オーバーヘッドは発生しないはずです。使用している実装を確認することで確認できます。おそらく、そのoperator->オーバーロードは、ポイントされたオブジェクトへのポインターを返すだけであり、そのオーバーロードは、operator*このポインターを逆参照するだけです。

（これは、Visual C ++ 2010の実装がstd::shared_ptr行うことです。これらのオーバーロードされた演算子はそれぞれ、ポインターを返すだけの「get」関数を呼び出すだけです。ロックやその他のオーバーヘッドはありません。他の実装は異なる場合があります。）

最適化されていないビルドは、演算子のオーバーロードをインライン化しない可能性があり、実装に有効にする追加のデバッグサポートがある場合、追加のチェックを実行する可能性があります（たとえば、nullポインターを逆参照する場合はアサート）。

于 2011-05-18T18:45:52.097 に答える
3

間接参照演算子を含む、スマートポインターのすべてのメンバー関数は、インライン化できます。優れたコンパイラは、抽象化を最適化する必要があります。

于 2011-05-18T18:45:21.947 に答える