18

すべてのコードでの使用にほぼ移行しましたが、シングルトンクラスなど、boost::shared_ptr使用するいくつかの孤立したケースがまだあります。std::auto_ptr

template < typename TYPE >
class SharedSingleton
{
public: 
    static TYPE& Instance()
    {
        if (_ptrInstance.get() == NULL)
            _ptrInstance.reset(new TYPE);
        return *_ptrInstance;
    }

protected: 
    SharedSingleton() {};

private:
    static std::auto_ptr < TYPE > _ptrInstance;
};

これが行われなかったのには非常に正当な理由があると言われましたがshared_ptr、私の人生ではその理由がわかりません。それauto_ptrは最終的に次の標準で減価償却としてマークされることを知っているので、この実装をどのように/どのように置き換えることができるかを知りたいです。

auto_ptrまた、？の代わりに使用することを検討する理由は他にありshared_ptrますか？また、将来、shared_ptrに移行する際に問題が発生することはありますか？

編集：

  1. したがって、「上記のコードで安全に置き換えることができますか」という答えでは、答えは「はい」です。ただし、パフォーマンスにわずかな影響を与えますauto_ptr。shared_ptr
  2. auto_ptr最終的に減価償却としてマークされ、に移動したらstd::shared_ptr、コードを徹底的にテストして、さまざまな所有権のセマンティクスに準拠していることを確認する必要があります。
4

3 に答える 3

36

auto_ptrshared_ptrまったく異なる問題を解決します。一方が他方を置き換えることはありません。

auto_ptrRAIIセマンティクスを実装するポインターの薄いラッパーであるため、例外に直面した場合でもリソースは常に解放されます。auto_ptr参照カウントなどをまったく実行せず、コピーを作成するときに複数のポインターが同じオブジェクトを指すようにしません。実際、それは非常に異なります。代入演算子がソースオブジェクトauto_ptrを変更する数少ないクラスの 1 つです。auto_ptr ウィキペディア ページのこの恥知らずなプラグインを検討してください。

int *i = new int;
auto_ptr<int> x(i);
auto_ptr<int> y;

y = x;

cout << x.get() << endl; // Print NULL
cout << y.get() << endl; // Print non-NULL address i

実行方法に注意してください

y = x;

y だけでなく x も変更します。

テンプレートを使用boost::shared_ptrすると、同じオブジェクトへの複数のポインターを簡単に処理できます。オブジェクトは、最後の参照が範囲外になった後にのみ削除されます。この機能は、 Singletonを実装する (しようとする) シナリオでは役に立ちません。あなたのシナリオでは、クラスの唯一のオブジェクトへの1つの参照への0つの参照が常に存在します。

本質的に、auto_ptrオブジェクトとshared_ptrオブジェクトはまったく異なるセマンティクスを持っています (そのため、コンテナーで前者を使用することはできませんが、後者を使用することは問題ありません)。コードの移植中に導入された回帰をキャッチするための適切なテストがあることを願っています。:-}

于 2009-08-04T13:06:11.057 に答える
14

auto_ptr他の人は、このコードが の代わりに を使用する理由を答えていshared_ptrます。その他の質問に対処するには:

この実装を何/どのように置き換えることができますか?

boost::scoped_ptrまたはunique_ptr(Boost と新しい C++ 標準の両方で使用可能) を使用します。と はどちらも厳密な所有権scoped_ptrをunique_ptr提供し (参照カウントのオーバーヘッドはありません)、 の驚くべきコピー時の削除のセマンティクスを回避しauto_ptrます。

auto_ptrまた、 の代わりに を使用することを検討する他の理由はありますshared_ptrか? shared_ptrまた、今後の移行に問題はありますか?

個人的には、私は使用しませんauto_ptr。コピー時に削除は直感的ではありません。 ハーブ・サッターも同意見です。scoped_ptr、unique_ptr、またはに切り替えてshared_ptrも問題はありません。具体的にshared_ptrは、参照カウントのオーバーヘッドを気にしない場合は、ドロップインの代替品にする必要があります。 の所有権移転機能をscoped_ptr使用していない場合は、簡単に置き換えられます。auto_ptr所有権の譲渡を使用している場合は、所有権を譲渡unique_ptrするために明示的に呼び出す必要があることを除いて、ほぼドロップインの代替品ですmove。例については、こちらを参照してください。

于 2009-08-04T13:33:56.457 に答える
1

auto_ptrは、私が使用する唯一の種類のスマートポインターです。Boostを使用しないため、また、ビジネス/アプリケーション指向のクラスでは、スマートポインターのコレクションや個々のスマートポインターに依存するのではなく、削除のセマンティクスと順序を明示的に定義することを一般的に好むため、これを使用します。

于 2009-08-04T13:01:57.550 に答える