問題タブ [boost-statechart]

これを修正する方法はありますか？

ubuntu 8.10 w / g++4.3.2で1.39_0を使用

次のステートチャートでは、「BUGGY」というフレーズが3回印刷されています。イベントがトリガーするのは1つの「BUGGY」だけであると予想されます。私が取り組んでいるプロジェクトの場合、イベントが複数の状態（通常は直交する状態のセットの奥深く）に到達する必要があるため、discard_event（）を返すことはできません。ステートチャートを変更する代わりに適用できる回避策がある場合は、知りたいです。

$ cat bug.cpp

$ g ++ bug.cpp && ./a.out
BUGGY
BUGGY
BUGGY

編集：：

これは、実際に取り組んでいるはるかに大きな問題で遭遇した問題を示すステートマシンの例です。topがevSayを転送することを私は知っています。c1、c2、c3はevSayに反応しないことに注意してください。これは、2つの状態がevSayに反応するように転送する必要がある例です。

出力：BUGGY
CHILD REACTION
BUGGY
BUGGY

私たちのプロジェクトには、UI とロジック (ステート マシンとして表される場合があります) があります。このステップ マシンのいくつかのステップ間の遷移は長い (IO バウンド)。遷移が進行している間ずっと UI スレッドを盗むことはしたくありません。したがって、この遷移を別のスレッドで実行し、遷移が終了したときに UI を更新する方法を探しています。

私は現在、このようなロジックを実装するオプションの 1 つとしてブースト ステートチャート ライブラリを評価していますが、それを使用してこのような長時間の遷移機能を実装する適切な方法は何ですか?

ありがとう。

ドキュメントの例に従って、custom_reaction<> が state<> の 3 番目のテンプレート パラメーターとして期待される概念と一致しないように見えるため、コンパイルに失敗する次のコードを作成しました。どうすれば本当に選択ポイントを作ることができますか? （これもブーストリストで聞いてみました）

Boostステートチャートライブラリを使用しており、コードの単体テストを作成するのに問題があります。

通常の実行では、ステートマシンは次の場所で起動しClosedStateます。

ステートマシンをその状態までトラバースすることなく、特定の状態遷移をテストしたいと考えています。たとえば、でテストを開始したいとしAnotherStateます。問題はsc::state_machine、初期状態でテンプレート化されていることです。テストされた状態につながるすべてのイベントをステートマシンに供給すると、通常、多くの作業が必要になり、テストが複雑になります。

原始的な解決策は、特別なデバッグ専用イベントを作成し、それをに追加することClosedStateです。このイベントは、への即時移行をトリガーしAnotherStateます。

タスクを達成するための他の方法を知っていますか？

ブーストには、ステート マシン用の 2 つの個別のライブラリが含まれているようです。StatechartとMeta State Machine (MSM) です。キャッチフレーズは、非常によく似た説明を提供します。

• Boost.Statechart - 任意の複雑な有限状態マシンを、読みやすく保守しやすい C++ コードで実装できます。
• Meta State Machine - 表現力豊かな UML2 有限状態マシン用の非常に高性能なライブラリ.

主な違いは何か、また、この 2 つを選択する際の考慮事項は何ですか?

まもなく取り組むプロジェクトのコンセプト コードをいくつか開発しました。このプロジェクトはステート マシンの設計に適しています。boost::statechart はうまく機能すると思います。ただし、 context() を使用しようとすると、障害が発生しました。以下にサンプルを示します (さらに多くのコードを掲載できることを嬉しく思いますが、これが重要な部分だと思います)。

ステート Active には「[over|under]flow_condition」と呼ばれるメソッドがあり、この時点で true を返します。設計の問題はさておき、このようにインスタンス化すると、次のアサーション エラーが発生します。

そしてここに主張があります：

アサーション "get_pointer( stt.pContext_ ) != 0" が失敗しました

このアサーションをファイル「/usr/include/boost/statechart/simple_state.hpp」の 689 行目 (boost 1.45) で調べたところ、simple_state がコンテキストを使用するのを防ぐためにあるとコメントがありました。ストップウォッチの例を再訪したとき、これは私を当惑させました。だから私はそれをコンパイルしましたが、このアサーションは当然のことながらストップウォッチ コードによって違反されていません。何か不足していますか？たぶん、コードのどこかに私が見逃したものがありますか? これがヘッダー全体です (概念コードであることを覚えておいてください...完全に一般化されるまで、これを公開しません):

私が書いていないステート マシンを変更する必要がある状況にあります。このステート マシンはBoost Statechartを使用して記述されます。残念ながら、このコードは解読不能であり、それを書いた人は休暇中です。

問題は単純だと思いますthing。これらの状態のいくつかで使用したい変数 があります。これは、情報を受け取る必要がある単一のアプリケーション コントローラーを表します。thingマシンの状態で利用できるようにするために、どのコンストラクター (または何でも) に与えることができますか?

状態は、次の例に従って宣言されます。

PSこの質問にはもっと良いタイトルが欲しいです。助けていただければ幸いです。

asynchronous_state_machine の processor_handle からスケジューラへの参照を取得することは可能ですか?

コード：

ブースト::ステートチャートで、ハレルのステートチャートとUMLステートチャートの比較のスライド25で説明されている初期状態選択を実装するためのいくつかの可能な方法は何ですか？

「超国家に入るとき、どの状態（X、Y、Z）に入るのかは、条件Cが何を評価するかによって異なります。」

ユニット テストでは、ステート マシン イベントを開始した後、すべてのステート トランザクションを記録しようとしています。
たとえば、イベント A を async_state_machine の fifo_scheduler に post_event A すると、ステート マシンはステート B、C を通過してから D に戻ります。すべてのイベント ステートを記録することはできません。単体テストを行うときに行われました:-(

私が考えることができる唯一のことは、作成したすべての状態のすべての反応メソッドまたはコンストラクターを変更して (simple_state から派生)、それらが記録を行うようにすることです。状態の react() メソッドを呼び出す直前に async_state_machine に本当にフックしたい場合、これは少しハックに思えます...