4

私は、メンバー間の関係を持ついくつかのパブリックユーザー定義クラスと、特定および汎用のシグネチャを持ついくつかのメソッドを持っています。

if/then/else、foreach、do/while、変数割り当てなどの基本的な制御ステートメントを使用して、これらのクラス (および CLR クラス) でカスタム制御フローを格納および操作できるようにしたいと考えています。

カスタム制御フローは実行時に作成し、後で使用および操作するために保存する必要があります。アイデアは、遺伝的操作を適用できるようにするために、厳密に型指定された構文を使用して、おそらく抽象的な構文ツリーの形式で、制御フローのデータ表現を持つことです。結果のカスタム コードは、別のプログラムの一部として実行する必要があります。

1）遺伝的操作を操作し、クラスを含むコードを実行するための推奨されるコード表現は何ですか。

2) 上記の問題には、どの c# テクノロジを使用する必要がありますか? リフレクション、新しい c# 3.0 機能 (ラムダ、式ツリー)、CodeDom、DLR ライブラリなどの関連テクノロジがあることは知っていますが、どのアプローチまたは組み合わせが最も効率的かを知っています。

3) 利用可能なそのようなパラダイムまたは実装はありますか?

編集: プラットフォームには、定数と時間変数の両方の定義済みの c# カスタム型のデータが提供されます。

刻々とルールがデータに適用され (基本的な条件またはより複雑な機能)、いくつかのアクションを実行することが決定されます。

私はできるようになりたいです：

ルールを木やグラフで表現し、その流れを実行します。

ユーザーが UI ツールキットを介してカスタム ルール セットを作成する

ツリーまたはグラフ上で再配置を行い、GP 操作を適用する

4

4 に答える 4

2

リフレクションは、すでに生成されたタイプ、メソッド、フィールドなどを検査するテクノロジーであるため、今のところあまり役に立たないでしょう。

式ツリーはかなり興味深いものですが、ラムダ式は本体を持つことができないため、複雑なプログラムフローを作成することはできません。これにより、適度に複雑なものを作成することがかなり困難になります。

DLRはやや作成中です。断片的な部分は入手できますが、DLRのサポートが組み込まれているのは次の.NETバージョンのみです。これは、プログラムをその場で作成して実行することにより、興味深い代替手段になる可能性があります。

今できることは、動的メソッドまたは動的に生成されたアセンブリのいずれかでILを放出することです。考えられるすべての構成が利用可能である必要がありますが、その後の操作はおそらくかなり困難です。

それでも、かなりのILマジックを実行するプロジェクトが1つあり、それはあなたにとって役立つ可能性があるものでさえあるかもしれません：LinFu。リストによると、動的オブジェクトの実装があり、dynamicObject.CreateDuck <InterfaceType>（）のようなことを行うことができます

少し重いかもしれませんが、興味深いもう1つのルートは、WF（Workflow Foundation）フレームワークです。このようなワークフローはプログラムによって構築可能である必要があり、継続スタイルが機能するため、興味深い場合があります。実行中のワークフローをいつでも永続化して、残した場所から取得できます。

従来のプログラム構造はすべて、WF内で利用できる必要があります。

于 2009-02-27T13:12:57.597 に答える
1

動的表現[例]APIは、この分野の分野をカバーしています。

于 2009-02-27T13:13:27.143 に答える
1

C# などの言語で表現されたプログラムの繁殖は非常にトリッキーです。単純に順応性を持たせるように設計されていません。変更のほとんどがプログラムの失敗を引き起こすだけであることがわかります。

2 つの代替アプローチのいずれかをお勧めします。

  1. 疑似機械語。2 種類の NOP でパターン マッチングを使用して、分岐またはループを可能にします。
  2. 名前付き関数の再帰を使用して反復を可能にする LISP リンク言語。

(1) 命令の線形シーケンスと何らかの形式の仮想レジスタまたはスタック マシンを使用して表現できます。(2) ツリーを使用して表現可能であり、何らかの形式の「縮小」アルゴリズムを使用して評価されます。

どのようなアプローチを使用する場合でも、サンドボックスでプログラムを実行する必要があります。無限ループが一般的であるため、設定されたサイクル数後にプログラムを停止できる必要があります。

于 2009-02-27T13:11:18.270 に答える
1

c# を出力するだけで (これをサポートする他の .net 言語の場合、f# もうまく機能します)、CodeDomProvider を使用してオンザフライでコンパイルします。IDynamicEntryPoint を実装する型を含めるために、指定されたコードを 1 つのソース ファイルに強制します (エントリ ポイントであり、構築後に呼び出される静的メソッドまたは空のコンストラクターを使用)。

これは、長期的に最高のパフォーマンスを得る可能性が最も高いと同時にすぐに試すことができるため、最初の呼び出しポートにする必要があります (動的 IL 出力がなければ、それでもコンパイラに勝てない可能性があります)。

これには明らかに、契約を破る可能性のある2つの欠陥があります。

  • 結果として得られるコードはセキュリティ上の悪夢です。完全に信頼できるユーザーからのコード入力のみを許可する必要があります。
  • 動的にコンパイルされたコードは、コード/インターフェイスの変更 (コードに含める必要がある dll のセットが変更されるか、一致しない可能性があります) に関して脆弱であるか、IDynamicEntryPoint の署名が変更される可能性があります。

楽しみのために独自の言語/パーサー/コンパイラーを作成することに興味がない限り、既にあるものを使用してください。

于 2009-02-27T14:02:56.570 に答える