shared_ptrを使用する場合の5つの落とし穴

shared_ptrクラスは、多くの開発者の問題を解決できる便利なツールです。 ただし、間違いをしないためには、彼のデバイスを完全に知る必要があります。 私の記事がこのツールを使い始めたばかりの人に役立つことを願っています。



以下についてお話します。

• 相互参照とは
• 危険な名前のないshared_ptrとは何ですか。
• マルチスレッド環境でshared_ptrを使用する場合、どのような危険が待っていますか。
• shared_ptrの独自のリリース関数を作成する際に覚えておくべき重要なこと;
• enable_shared_from_thisテンプレートを使用する機能は何ですか。

説明されている問題は、boost :: shared_ptrとstd :: shared_ptrの両方で発生します。 記事の最後に、記述された機能を実証するために書かれたプログラムの全文を含むアプリケーションがあります（例としてboostライブラリを使用）。

相互参照

この問題は最も有名であり、shared_ptrポインターが参照カウントに基づいているためです。 shared_ptrが所有するオブジェクトのインスタンスの場合、カウンターが作成されます。 このカウンターは、このオブジェクトを指すすべてのshared_ptrに共通です。







新しいオブジェクトを作成すると、カウンターを持つオブジェクトが作成され、その中に値1が配置されます。コピーすると、カウンターが1ずつ増加します。



例を考えてみましょう：

struct Widget { shared_ptr<Widget> otherWidget; }; void foo() { shared_ptr<Widget> a(new Widget); shared_ptr<Widget> b(new Widget); a->otherWidget = b; //         = 2 b->otherWidget = a; //         = 2 }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

オブジェクトaとbがスコープから出るとどうなりますか？ デストラクタでは、オブジェクトへの参照が減少します。 各オブジェクトには、カウンター= 1があります（結局、aはbを指し、bはaを指します）。 オブジェクトはお互いを「保持」し、アプリケーションはそれらにアクセスする機会がありません-これらのオブジェクトは「失われます」。

この問題を解決するweak_ptrがあります。 典型的な相互参照のケースの1つは、1つのオブジェクトが他のオブジェクトのコレクションを所有している場合です。

 struct RootWidget { list<shared_ptr<class Widget> > widgets; }; struct Widget { shared_ptr<class RootWidget> parent; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このようなデバイスでは、各ウィジェットはルートウィジェットの削除を防ぎ、逆も同様です。







この場合、「誰が誰を所有していますか？」という質問に答える必要があります。 明らかに、ウィジェットオブジェクトを所有するのはこの場合はRootWidgetであり、その逆ではありません。 したがって、次のように例を変更する必要があります。

 struct Widget { weak_ptr<class RootWidget> parent; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

弱いリンクは、オブジェクトの削除を妨げません。 これらは、2つの方法で強さに変換できます。



1）コンストラクターshared_ptr

 weak_ptr<Widget> w = …; //  ,    ,   shared_ptr    shared_ptr<Widget> p( w );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2）ロック方法

 weak_ptr<Widget> w = …; //  ,    ,  p    if( shared_ptr<Widget> p = w.lock() ) { //     –     }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結論：

コード内のリング参照の場合、weak_ptrを使用して問題を解決します。

名前のないポインター

名前のないポインターの問題は、「シーケンスポイント」の問題を指します。

 // shared_ptr,     foo -  foo( shared_ptr<Widget>(new Widget), bar() ); // shared_ptr,     foo   p shared_ptr<Widget> p(new Widget); foo( p, bar() );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらの2つのオプションのうち、ドキュメントでは、常に2番目の名前を使用することを推奨しています。 bar関数が次のように定義されている例を考えてみましょう。

 int bar() { throw std::runtime_error(“Exception from bar()”); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際には、最初のケースでは、設計順序は定義されていません。 それはすべて、特定のコンパイラとコンパイルフラグに依存します。 たとえば、これは次のように発生します。

1. 新しいウィジェット
2. バー関数呼び出し
3. shared_ptrの構築
4. foo関数呼び出し

fooの呼び出しが最後のアクションになり、オブジェクト（新しいウィジェット）の作成後にshared_ptrが構築されることのみを確認できます。 ただし、オブジェクトの作成直後に構築されるという保証はありません。



2番目のステップで例外がスローされた場合（この例ではスローされます）、ウィジェットは構築されたと見なされますが、shared_ptrはまだそれを所有していません。 その結果、このオブジェクトへのリンクは失われます。 この例をgcc 4.7.2でテストしました。 呼び出しの順序は、共有オプションに関係なく、shared_ptr + newがbarの呼び出しによって分離されないようなものでした。 しかし、そのような振る舞いだけに頼る価値はありません-保証されていません。 コンパイラ、バージョン、およびそのようなコードがエラーにつながるコンパイルオプションを教えてくれればありがたいです。



匿名のshared_ptr問題を回避する別の方法は、make_sharedまたはallocate_shared関数を使用することです。 この例では、次のようになります。

 foo( make_shared<Widget>(), bar() );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例は、元の例よりも簡潔に見えるだけでなく、メモリの割り当てに関して多くの利点があります（効率の問題は記事の範囲外にします）。 任意の数の引数を指定してmake_sharedを呼び出しましょう。 たとえば、次のコードは、1つのパラメーターを持つコンストラクターによって作成された文字列にshared_ptrを返します。

 make_shared<string>("shared string");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結論：

コードがこれより簡潔でない場合でもshared_ptr名を付けるか、オブジェクトの作成に使用します

make_sharedおよびallocate_shared関数。

異なるスレッドで使用する問題

shared_ptrのリンクカウントは、アトミックカウンターを使用して構築されます。 異なるスレッドから同じオブジェクトへのポインタを安全に使用します。 いずれにせよ、参照カウントを心配することに慣れていません（オブジェクト自体のスレッドセーフは別の問題です）。



グローバルなshared_ptrがあるとします：

 shared_ptr<Widget> globalSharedPtr(new Widget); void read() { shared_ptr<Widget> x = globalSharedPtr; //  -  Widget }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

異なるスレッドから読み取り呼び出しを実行すると、コードに問題がないことがわかります（ウィジェットでこのクラスのスレッドセーフ操作を実行している場合）。



別の関数があると仮定します。

 void write() { globalSharedPtr.reset( new Widget ); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

shared_ptrデバイスは非常に複雑なので、問題を模式的に示すコードを提供します。 もちろん、このコードは異なって見えます。

 shared_ptr::shared_ptr(const shared_ptr<T>& x) { A1: pointer = x.pointer; A2: counter = x.counter; A3: atomic_increment( *counter ); } shared_ptr<T>::reset(T* newObject) { B1: if( atomic_decrement( *counter ) == 0 ) { B2: delete pointer; B3: delete counter; B4: } B5: pointer = newObject; B6: counter = new Counter; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初のスレッドがglobalSharedPtr（読み取り）のコピーを開始し、2番目のスレッドが同じポインターインスタンス（リセット）に対してresetを呼び出したとします。 結果は次のようになります。

1. スレッド1は行A2を完了しましたが、まだ行A3に移動していません（アトミック増分）。
2. この時点でStream2は、ラインB1のカウンターを減らし、カウンターを減らした後、カウンターがゼロになり、ラインB2とB3を完了することを確認しました。
3. Thread1は行A3に到達し、すでになくなっているカウンターをアトミックに増加させようとします。

または、行A2のstream1には、stream2がオブジェクトを削除する前に、stream2がカウントダウンした後にカウンターをインクリメントする時間があります。 次に、リモートカウンターとオブジェクトを指す新しいshared_ptrを取得します。



同様のコードを書くことができます：

 shared_ptr<Widget> globalSharedPtr(new Widget); mutex_t globalSharedPtrMutex; void resetGlobal(Widget* x) { write_lock_t l(globalSharedPtrMutex); globalSharedPtr.reset( x ); } shared_ptr<Widget> getGlobal() { read_lock_t l(globalSharedPtrMutex); return globalSharedPtr; } void read() { shared_ptr<Widget> x = getGlobal(); //    x    } void write() { resetGlobal( new Widget ); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、このような関数を使用して、このshared_ptrを安全に操作できます。



結論：いくつかのshared_ptrインスタンスが異なるスレッドで利用可能であり、変更できる場合、このshared_ptrインスタンスへのアクセスを同期させる必要があります。

shared_ptrのリリースファンクターの破棄時間の特性

この問題は、独自のリリースファンクターを弱いポインター（weak_ptr）と組み合わせて使用​​する場合にのみ発生します。 たとえば、削除前に新しいアクションを追加することで、別のshared_ptrに基づいてshared_ptrを作成できます（基本的には「Decorator」テンプレート）。 したがって、接続プールからデータベースを削除することで、データベースを操作するためのポインターを取得し、クライアントがポインターの操作を終了したら、プールに戻すことができます。

 typedef shared_ptr<Connection> ptr_t; class ConnectionReleaser { list<ptr_t>& whereToReturn; ptr_t connectionToRelease; public: ConnectionReleaser(list<ptr_t>& lst, const ptr_t& x):whereToReturn(lst), connectionToRelease(x) {} void operator()(Connection*) { whereToReturn.push_back( connectionToRelease ); //      connectionToRelease.reset(); } }; ptr_t getConnection() { ptr_t c( connectionList.back() ); connectionList.pop_back(); ptr_t r( c.get(), ConnectionReleaser( connectionList, c ) ); return r; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

問題は、shared_ptrのリリースファンクタとして渡されたオブジェクトは、オブジェクトへのすべての参照が破棄されたときにのみ破棄されることです-強い（shared_ptr）と弱い（weak_ptr）の両方です。 したがって、ConnectionReleaserが渡されたポインターを「解放」することに注意しない場合（connectionToRelease）、getConnection関数によって作成されたshared_ptrから少なくとも1つのweak_ptrがある限り、強力なリンクを保持します。 これは、アプリケーションの非常に不快で予期しない動作を引き起こす可能性があります。



また、バインドを使用してリリースファンクタを作成することもできます。 たとえば、次のように：

 void releaseConnection(std::list<ptr_t>& whereToReturn, ptr_t& connectionToRelease) { whereToReturn.push_back( connectionToRelease ); //      connectionToRelease.reset(); } ptr_t getConnection() { ptr_t c( connectionList.back() ); connectionList.pop_back(); ptr_t r( c.get(), boost::bind(&releaseConnection, boost::ref(connectionList), c) ); return r; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

bindは渡された引数をコピーすることに注意してください（boost :: refを使用する場合を除く）。それらの間にshared_ptrがある場合は、既に説明した問題を回避するためにクリアする必要があります。



結論：リリース機能で、最後の強力なリンクを切断するときに実行する必要があるすべてのアクションを実行します。 何らかの理由でファンクターのメンバーであるすべてのshared_ptrをリセットします。 バインドを使用する場合、渡された引数をコピーすることを忘れないでください。

enable_shared_from_thisテンプレートを使用する機能

オブジェクト自体のメソッドからshared_ptrを取得する必要がある場合があります。 これから新しいshared_ptrを作成しようとすると、これが一般的な慣習であるintrusive_ptrとは異なり、未定義の動作（プログラムをクラッシュさせる可能性が最も高い）につながります。 この問題を解決するために、テンプレート混合クラスenable_shared_from_thisが発明されました。



enable_shared_from_thisテンプレートの構造は次のとおりです。クラスにはweak_ptrが含まれます。これは、shared_ptrを作成するときに、このshared_ptrへの参照を含みます。 オブジェクトのshared_from_thisメソッドを呼び出すと、weak_ptrは、コンストラクターを介してshared_ptrに変換されます。 概略的には、テンプレートは次のようになります。

 template<class T> class enable_shared_from_this { weak_ptr<T> weak_this_; public: shared_ptr<T> shared_from_this() { //        shared_ptr shared_ptr<T> p( weak_this_ ); return p; } }; class Widget: public enable_shared_from_this<Widget> {};
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合のshared_ptrコンストラクターは次のようになります。

 shared_ptr::shared_ptr(T* object) { pointer = object; counter = new Counter; object->weak_this_ = *this; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

オブジェクトを構築するとき、weak_this_はまだ何も示さないことを理解することが重要です。 構築されたオブジェクトがshared_ptrコンストラクターに渡された後にのみ、正しいリンクが表示されます。 コンストラクターからshared_from_thisを呼び出そうとすると、bad_weak_ptr例外がスローされます。

 struct BadWidget: public enable_shared_from_this<BadWidget> { BadWidget() { //   shared_from_this()   bad_weak_ptr cout << shared_from_this() << endl; } };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

デストラクターからshared_from_thisにアクセスしようとすると、同じ結果になりますが、別の理由で、オブジェクトの破壊時には、強力なリンクがそれを指していないと既に考えられています（カウンターは減少します）。

 struct BadWidget: public enable_shared_from_this<BadWidget> { ~BadWidget() { //   shared_from_this()   bad_weak_ptr cout << shared_from_this() << endl; } };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2番目のケース（デストラクタ）では、ほとんど考えられません。 唯一のオプションは、shared_from_thisを呼び出さないように注意し、デストラクタが呼び出す関数が呼び出さないようにすることです。



最初のケースは少し単純です。 オブジェクトが存在する唯一の方法はshared_ptrであると既に決定しているので、オブジェクトのコンストラクターをクラスのプライベート部分に移動し、必要なタイプのshared_ptrを作成する静的メソッドを作成することが適切です。 オブジェクトの初期化中にshared_from_thisを必要とするアクションを実行する必要がある場合、この目的のために、initメソッドでロジックを選択できます。

 class GoodWidget: public enable_shared_from_this<GoodWidget> { void init() { cout << shared_from_this() << endl; } public: static shared_ptr<GoodWidget> create() { shared_ptr<GoodWidget> p(new GoodWidget); p->init(); return p; } };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結論：

コンストラクターおよびデストラクターから（直接または間接）shared_from_thisを呼び出さないでください。 オブジェクトの適切な初期化にshared_from_thisへのアクセスが必要な場合：initメソッドを作成し、オブジェクトの作成を静的メソッドに委任して、このメソッドを使用してのみオブジェクトを作成できるようにします。

おわりに

この記事では、shared_ptrを使用する5つの機能について説明し、潜在的な問題を回避するための一般的な推奨事項を提供します。



shared_ptrは開発者から多くの問題を取り除きますが、shared_ptrを適切に使用するには、内部デバイスの知識（ほぼではありますが）が必須です。 shared_ptrデバイスとそれに関連するクラスを慎重に検討することをお勧めします。 いくつかの単純なルールを順守することで、開発者は不要な問題を回避できます。

文学

• Boost.orgのドキュメント
• スコット・マイヤーズ「より効果的なC ++：プログラムとデザインを改善する35の新しい方法」

アプリ

付録には、記事で説明されているケースを説明するためのプログラムの全文が含まれています。