問題タブ [boost-signals]

Boost.Signals はスレッドセーフではないことを複数の場所で読みましたが、詳細はわかりませんでした。この単純な引用は、それほど多くを語っていません。現在、ほとんどのアプリケーションにはスレッドがあります。シングル スレッドにしようとしても、一部のライブラリはスレッドを使用する場合があります (libsdl など)。

他のスレッドがスロットにアクセスしないという実装の問題はないと思います。したがって、少なくともこの意味ではスレッドセーフです。

しかし、正確には何が機能し、何が機能しないのでしょうか? 同時にアクセスしない限り、複数のスレッドから使​​用することはできますか? つまり、スロットの周りに独自のミューテックスを構築した場合はどうなりますか?

それとも、スロットを作成したスレッドでのみスロットを使用する必要がありますか? または、初めて使用した場所はどこですか？

私はブースト ライブラリを使用しています。私の質問は、boost::signals に関するものです。
多くの異なるスロットを呼び出す可能性のあるシグナルがありますが、1 つのスロットのみが呼び出しに一致するため、この特定のスロットが true を返し、呼び出しが停止するようにします。
出来ますか？
効率的ですか？
効率的でない場合、より良い方法を提案できますか？

boost.asio には、パケットを受信するたびにコールバック関数を呼び出すメカニズムがあることは知っていますが、代わりにシグナルを送信するオプションはありますか?
シグナルを発する関数を書く必要がありますか?
もしそうなら、なぜですか？

次のコード行は、問題なく正しくコンパイルされます。

ただし、boost::functionに割り当てる場合、または次のようなコールバックとして割り当てる場合:

理解できないエラーが大量に発生しています (ここに収まらないほど長いため、リンクされています)。

一方、次のように無料のシグナルを boost::function にバインドすることに成功しました。

session connectedこれは機能し、正しく印刷されます。ここで何が間違っていますか？

boost.signals ライブラリのシグナルから特定のスロットの削除をブロックすることは可能ですか?
もしそうなら、そのようなことを行うコードはどのように見えるでしょうか? その特定のシグナルのためだけに派生クラスを作成する必要がありますか?

私は現在、コールバックを介して他の多くのオブジェクトに通知できるクラスを持っています:

これを変更してブーストのシグナルとスロットを使用することを検討しています。これは、特に、呼び出し先が削除されたときにポインターがぶら下がる可能性を減らすのに役立つためです。ただし、現状では、boost のシグナルは、関数オブジェクトを処理する方向に向いているようです。接続と通知の側面に対処するためにシグナルとスロットを使用し、コールバック インターフェイスを引き続き使用するようにコードを適応させる最良の方法は何でしょうか?

私は g++ でビルドしていますが、昨日、SO の親切な人から-D_GLIBCXX_DEBUGand-D_GLIBCXX_DEBUG_PEDANTICフラグでコンパイルするように言われました。私はそうし、昨日のほとんどをこれらのフラグに準拠するようにコードを微調整することに費やしました。の使用について不平を言っていますがboost::signal、どこに問題があるのか​​ わかりません。

別のクラスのシグナルにバインドしたいYarl関数を持つクラスがあります:refresh()sigRefreshEventHandler

次に、のメンバー関数にはYarl、次のコードがあります。

これらのフラグを使用してコンパイルを開始する前は、このコードは問題なく動作していました。それらを使用するようになったので、私のプログラムは 2 行目でセグメンテーション違反を起こします。

gdb からのバックトレースは次のとおりです。

私が何を修正すべきか誰にもわかりますか？

編集: Daniel Trebbien が提案したように、問題を説明する小さなサンプル プログラムがあります。

ヘッダー ファイル (test.hpp) は次のとおりです。

実装は次のとおりです。

前と同様に、このサンプル プログラムは g++ で-gフラグのみを使用してコンパイルすると正常に動作しますが、 and を追加する-D_GLIBCXX_DEBUGと-D_GLIBCXX_DEBUG_PEDANTIC、その行で segfault が発生しeventHandler.sigRefresh.connectます。

Boost を-D_GLIBCXX_DEBUGand-D_GLIBCXX_DEBUG_PEDANTICで再コンパイルしましたが、問題は解決しませんでしたが、コンパイル中に奇妙なことをしていることに気付きました。このコマンドを使用して bjam でコンパイルしました (このブースト チュートリアルによると):

タグにもかかわらず、--variant=debugまだリリース バージョンをコンパイルしていました。また、出力のどこにもデバッグ フラグについての言及はありませんでした。間違ってコンパイルした可能性はありますか？

コード内に、 2つのにバインドしたいYarlメンバー関数を持つクラスがあります。これらのシグナルの1つは、次のように定義されたクラスのメンバーです。refreshboost::signalEventHandler

もう1つは、次のように宣言された別のファイルのフリーフローティング信号です。

のメンバー関数で、次のようなシグナルYarlに接続します。refresh

その後、両方のシグナルを次のように呼び出します。

このコードはコンパイルおよび実行sigRefreshされ、期待どおりに機能します。ただし、を呼び出しても何も起こりませんsignal_refresh。私の知る限り、refresh実際にに接続されることはありませんでしたsignal_refresh。誰かが私が間違っているのを見ますか？

私は C# と C++ の両方でプログラミングするのが好きなので、計画中の C++ SFML-GUI の強固な基盤として、C# のようなイベント システムを実装しようとしています。

これは私のコードの抜粋に過ぎず、これが私の概念を明確にすることを願っています:

ご覧のとおり、boost::signal を実際のイベント システムとして使用していますが、イベント リスナーが operator() を介してイベントを発生させないように、IEvent インターフェイス (実際には抽象クラス) でカプセル化しています。

便宜上、加算代入演算子と減算代入演算子をオーバーロードしました。IEventListener からイベント リスニング クラスを派生させれば、シグナル内で関数ポインターがぶら下がっていることを気にせずにコードを記述できます。

これまでのところ、結果をテストしていますが、次のことに問題がありstd::tr1::function::target<TFuncPtr>()ます。

このEventHandler<TEventArgs>::target<TFuncPtr>()メソッドは、共分散に関係なく、TFuncPtr が Functor に格納されている型とまったく同じ型である場合にのみ、有効なポインターを返します。RTTI チェックのため、標準の弱く型付けされた C 関数ポインターとしてポインターにアクセスすることは禁止されています。

EventHandler は DerivedEventArgs 型ですが、関数がコンストラクターを介して実行されたとしても、pfnBaseEventHandler 関数を指しています。

つまり、 std::tr1::function 自体が反変性を「サポート」していますが、その型がわからない場合、 std::tr1::funcion オブジェクトから関数ポインターを単純に取得する方法を見つけることができませんテンプレート引数に必要なコンパイル時。

このような場合、RAII ポインター型の場合と同様に単純な get() メソッドを追加していただければ幸いです。

私はプログラミングにまったく慣れていないので、できればテンプレートを介してコンパイル時にこの問題を解決する方法があるかどうかを知りたいです (これが唯一の方法だと思います)。