5

このような小さな関数内で scoped_ptr を使用しています。削除を呼び出す必要がないように。これは、この使用法ではやり過ぎですか? 私のチーム メンバーは生のポインターと削除を好みます。これが非常にクリティカルなパスで使用された場合、scoped_ptr を使用するコストはいくらですか? これはインライン化されるべきではなく、最適化されたバイナリで通常の削除を使用するのとまったく同じではないでしょうか?

void myfunc()
{
  boost::scoped_ptr<myobj> objptr = someFactory::allocate();
  callsomeotherfunc(objptr.get());
}
4

4 に答える 4

8

パフォーマンス ヒットについては確信が持てませんが、ここで使用すると、例外が安全であることがscoped_ptr保証されます。例外がスローされた場合、動的に割り当てられたメモリは引き続き解放されます。が使用されておらず、スローされる可能性がある場合、関数は次のように構成する必要があります。myfunc()callsomeotherfunc()scoped_ptrcallsomeotherfunc()

void myfunc()
{
    myobj* objptr = someFactory::allocate();

    try
    {
        callsomeotherfunc(objptr);
        delete objptr;
    }
    catch (const some_exception&)
    {
        delete objptr;
        throw;
    }
}

関数の今後のすべての変更では、delete objptr;可能性のあるすべての出口点で が呼び出されるようにする必要があるため、これはエラーが発生しやすくなります。

于 2012-04-27T12:54:25.367 に答える
3

私はscoped_ptrその目的には使用しませんがunique_ptr、C ++ 11とauto_ptr古いコンパイラで使用します。どちらも、特定のユースケースと同等です。それがやり過ぎであるかどうかに関しては、いいえ、そうではありません。例外安全性を提供するための唯一のオプションです（コード内のいずれかmyfuncまたはcallsomeotherfuncスローのいずれかを言うと、メモリを解放する必要があります）。パフォーマンスの面では、3つのオプションはdelete、例外がスローされない場合に関数の最後で呼び出しを行うのと同等であり、例外が発生した場合に例外を再スローするtry/catchブロックを使用するよりも高速deleteです。

さらに、ファクトリから割り当てているようです。一部の設計では、ファクトリにはdeallocate、ではなく、呼び出す必要のある操作がありますdelete。その場合は、別のスマートポインタを検討することをお勧めします（標準とは異なり、メモリを解放する適切な方法であるshared_ptr場合はやり過ぎです。または、削除機能を提供することもできます） 。deletemanaged_ptr

于 2012-04-27T12:57:15.660 に答える
0

いいえそうではありません。スマートポインタを使用する利点（例外安全性や自動リソースクリーンアップなど）は、スマートポインタの作成、保守、および破棄に必要な2バイトのメモリと2つの追加CPUクロックを使用することによるパフォーマンスの低下よりもはるかに高くなります。

于 2012-04-27T12:56:21.920 に答える
0

scoped_ptr の使用に相当するものは次のようになると思います。

void myfunc()
{
  myobj* objptr = someFactory::allocate();
  try
  {
      callsomeotherfunc(objptr);
  }
  catch (...)
  {
      delete objptr;
      throw;
  }
  delete objptr;
}

どのバージョンを書きたいかはわかっています...

于 2012-04-27T12:58:42.827 に答える