1

最近、本業の一環として、IBM Rhapsody を学習し、それを使用して UML から C++ でコードを生成しています。

昨日、自分の C++ コンパイラにステート マシンのサポートを追加することを考えるのはクールかもしれないと思い、ここにいくつかメモを書き留めました。

これを行う私の動機は次のとおりです。

  1. クールなアイデアのようです。
  2. コンパイラーは、現在の Rhapsody/通常の C++ コンパイラーよりもはるかに優れたセマンティック チェック (より優れたエラー チェックを含む) を実行できます。
  3. コンパイラ自体がステート マシンの構造を理解している場合、多くの最適化の可能性があります。

提案のようなものを除いて、それがどれほどうまく機能するかを確認するために、文法を拡張しようとするかもしれません.

その提案についてどう思いますか。読みやすそうですか？価値があるように見えますか？

編集：

ステート マシンを実行するために特定のライブラリを推奨する回答に感謝しますが、それは私の質問ではありませんでした。私は、ライブラリと私が書いたコードの両方を使用して、多くのステート マシンを実装してきました。

この変更が標準 C++ への追加に適しているかどうかではなく、C++ ライクな言語へのステート マシン拡張の設計に関するアイデアや批判などを本当に探していました。私のドメインがリアルタイム制御アプリケーションであるドメイン固有の拡張機能と考えてください。

ここで説明されているように、コンパイラで拡張機能の実装を開始しました: http://ellcc.org/wiki/index.php/State%5Fmachines%5Fand%5FActive%5FClasses

これまでのところ、提案から実装に至るまでコンセプトを大きく変更する必要はありませんでしたが、詳細にいくつかの変更があり、問題のセマンティクスの理解を深めています。

ただし、コンセプト全体に価値があるかどうかは、時が経てばわかります。;-)

4

6 に答える 6

9

いくつかの例外を除いて、C++ は従来、新しいキーワードではなく、クラス ライブラリを使用して拡張されてきました。ステート マシンは、このようなライブラリを使用して簡単に実装できるため、あなたの提案が実現する可能性はあまりないと思います。

あなたの提案に見られる 1 つの問題は、'goto' を使用して別の状態に移動することです。状態遷移内の自分のコードで goto を使用したい場合はどうなりますか?

于 2009-12-05T14:17:20.707 に答える
2

別の賢い開発者が C に似た言語にステート マシンのサポートを追加した方法を見てみましょう: UnrealScript 言語リファレンス。「状態」という名前のセクションを参照してください。

UnrealScript は、言語レベルでステートをサポートします。UnrealScript では、世界の各アクターは常に 1 つだけの状態になります。その状態は、実行したいアクションを反映しています。たとえば、移動ブラシには、「StandOpenTimed」や「BumpOpenTimed」などのいくつかの状態があります。ポーンには、「瀕死」、「攻撃中」、「放浪中」などのいくつかの状態があります。UnrealScript では、特定の状態に存在する関数とコードを記述できます。これらの関数は、アクターがその状態にある場合にのみ呼び出されます

于 2009-12-13T17:41:13.810 に答える
2

あなたがしたことを発展させる素晴らしい仕事。あなたがやったことのようなことはおそらく可能ですが、それがC++に入るとは思えません。言語自体に加えられるほとんどの変更は、人々がより便利で強力なライブラリを作成できるようにするためだけに含まれています。

ここには、ステート マシンのサポートを提供するライブラリがあります。私は試していませんが、興味があるかもしれません。あなたのアイデアをこのようなライブラリと組み合わせて、他の人がそれを利用できるようにすることができるかもしれません。

http://www.boost.org/doc/libs/1_34_1/libs/statechart/doc/index.html

または、あなたが提案するように独自の拡張機能を開発することもできます。それは少なくともあなたにとっては役に立ちます。Microsoft はいくつかの拡張キーワードを実装しているため、独自の拡張バージョンの C++ を作成できない理由はありません。

新しいアイデアを出し続けてください。

于 2009-12-05T14:27:44.770 に答える
1

あなたの提案を読んで、次のコメントをしてください。

  1. 実際のステート マシンを宣言および定義するためのキーワードは実際にはありません。単一のグローバル ステート マシン (つまり、単一のグローバル ステート) を想定していますか? それはどのように関係してい__active__ますか？

  2. C++ で最も近い比較可能な構造は、実際には列挙型です。なぜ延長しないのですか？

  3. 定義されたイベントと状態の間に何らかの関連があるようですが、それがどのように実装されているかわかりません。

  4. なぜスレッドとタイマーが必要なのですか? ステート マシンのいくつかのユース ケースはそれらから恩恵を受ける可能性がありますが、適切な提案ではこれらを分離しておく必要があります。最も重要なことは、これにより標準の C++0x スレッドを使用できるようになることです。

個人的には、列挙構文を拡張します。

enum Foo {
  red, blue, green; /* Standard C++ so far - defines states. State list ends with a ; not a , */ 
  Foo() { *this = red; } // Reuse ctor syntax, instead of __initial__
  ~Foo() { } // reuse dtor syntax, instead of __onexit__

  void Bar() {/**/} // Defines an event, no return value. Doesn't need keyword __event__
};

当然のことながら、イベントをヘッダーで宣言し、.cpp ファイルで定義できるようになりました。ここで構文を提案する必要さえありません。この時点で、C++ プログラマーなら誰でも推測できます。結合された状態の継承構文を少し追加します。

enum DrawingObject : public Shape, public Color { /** } // allows (red && circle)

新しいキーワードを使用せずに、すでに使い慣れた構文をすべて再利用することで、提案がほぼ完成しています。

于 2009-12-15T15:07:47.743 に答える
1

あなたのソリューションは、テンプレートまたはプリプロセッサ マクロ ベースのソリューションに比べて利点があるようには見えません。

また、より良いセマンティックチェックを提供する方法もわかりません。また、多くの有用なコード最適化を適用できるとは思えません。

ただし、より適切な最適化とセマンティック チェックを可能にするために、「goto」を新しいキーワード (例: __change__ newState) に置き換え、状態の変更に対して goto を許可しないようにする必要があります。通常どおり、ローカル ジャンプの goto を許可します。

次に、コンパイラは可能な遷移のリストを抽出できます。

于 2009-12-13T18:12:02.293 に答える
1

これは興味深いアイデアですが、C++ を正式に拡張するよりも、ステート マシン用の独自のドメイン固有言語を作成した方が実際にはうまくいくと思います。C++ は、非常に汎用的なプログラミング言語として設計されています。Boost は、ライブラリを使用してほとんどの機能を適切に実装できる C++ の柔軟性を証明したと思います。また、標準 C++ には 2009 年の時点で組み込みのスレッド サポートさえないという点で、非常にゆっくりと進化しています (これは 0x で計画されています)。したがって、委員会がこの追加をしばらく検討する可能性は低い.

于 2009-12-05T14:23:29.270 に答える