トレースタスク(関数グラフの作成)

 

あるコード(関数、クラスなど)があるとします。

コールスタックを 作るというタスクがあります。しかし、ただの直線的なものではなく、木として です。

ここで、ツリーノードは関数のエントリになり、ブランチは現在の関数ノードから次の関数の呼び出しになります。

例えば、こんな機能の仕組みがあります。

void Main() {  A(); B(); }

void A() { /*вошли в А*/ a(); b(); c(); }
void B() { /*Вошли в B*/ a(); b(); c(); }

void a() { /*Вошли в а */ }
void b() { /*Вошли в b */ }
void c() { /*Вошли в c */ }

結果は次のようになります。


義務的な条件。

既存のコード関数に1つだけ、"{"の直後に関数を追加することで、トレースをアレンジすることができます。
ソース関数の入力パラメータやその結果、内部のコードなどを一切変更しないでください。

この条件は、大規模なコード改変を行わず、既存のコード関数に同じトレース関数(例えば_TRACE_IN_と名付ける)を挿入するために必要なものである。ソースコードの全パスを取得し、コールツリーを構築するため。


アイデアやバリエーションがあれば、ぜひ教えてください。
どう回しても、このようなツリーを形成するために、1つだけでなく2つの関数を呼び出さなければならないという悪循環に陥ってしまうのです。でも、1つでいいのかもしれません。:)

 

そこで、ソースのアルゴリズムを検出するためのプログラムを作りたいわけです。

自分もAsmで他人のプログラムを壊すときに似たようなことをやっていましたが、あなたのやり方は理解できません...。

なぜ木の形なのか?

とか、よくわかんないけど

 
FLET:

つまり、ソースのアルゴリズムを検出するプログラムを作りたいのですね。
自分もAsmで他人のプログラムを壊すときに似たようなことをしましたが、あなたのアプローチは理解できません......。

、よくわからないのですが、なぜ木なのでしょうか?


壊す」ことは考えていませんでした。でも、ちゃんと届いていますよ。論理的なコード構造を構築するためのものです。

つまり、私のタスクは、動作中のコード(私自身または他の人のもの、あるいは例えばMT5の標準配信から)をオンにすると、別のウィンドウで、呼び出された関数の スタック全体をツリーとして取得することです。つまり、ルート - 関数start() で、そこから上へ上へと......。

ツリーはとっくに実装しています。関数に費やした時間(コード品質の分析用)、関数の呼び出し回数、変数値のトレースなどの分析機能を持つ。また、このツリーを表示する方法として、スクリーンショットにあるような表示方法と、円グラフ、折れ線グラフの3種類を実装しました。でも、すべて小さなことのためにやっていたんです。

一番苦労したのは、ツリー構造そのものを埋めることでした。

スクリーンショットのような構造を構築するために、ソースコードの関数に追加された1つの関数(またはいくつかの割り当て、しかし主なものは、それらが一列にあることです)を使用する方法を教えて ください。

 
sergeev:

画面のような構造を、コード関数の先頭に追加した1つの関数だけで 構築する方法を教えてほしい。

アイデアの 不可能性の証明でいいのか?
 
MetaDriver:
アイデアの 不可能性を証明すれば、それでいいのか?

は...ただし、3ページにわたる選択肢の議論の末にです :))

複雑な実装、余分な変数、グローバルの使用など、何でもOKです :)

 
sergeev:

は...が、3ページにも及ぶ選択肢の議論の末に :))
ランです。4ページ目を待っています;-)
 
sergeev:

それだけの価値がある......。が、3ページにも及ぶバリアントの議論の末に :))


ということは、3ページ分の文章でトピックを埋めるというタスクになったのですね。:), OK, やってみましょう ;)

1. 文字列を扱う:関数を入力、関数名を追加、関数を削除 終了、ログ/トレース 完全な文字列を線形リストとして恒久的に出力する。

start(enter)-func1(enter)-func2(enter)

start(入力)-func1(入力)-func2(終了)

...

権兵衛が種蒔きゃ烏賊がほじくる

2。手動でコード内の関数の数をカウントし、この数は、ブール代数を使用して、10関数のコードで=ベース10、3関数のコードで=ベース3、すなわち、番号付けシステムになりますまたは多分マトリックスを使用して簡単に、除外操作を実行したり、関数の入力/出力に含めることができます。

おおよそそうですが、それにしてもイモトは-手間をかける価値があるのでしょうか?

 

IgorM:

では、課題は3ページのテキストでトピックを埋めることに絞られたのですか?:), OK, 行くわよ ;)

おいおい、そんなに暑くないだろ!ここでは全ページをカウントしているんだぞ!(笑)

1. 文字列の操作:関数の入力、関数名の追加、関数の終了、関数の削除。

条件と合わない。通話は1回 だけでいいんですよ、エントリー時に。出口で非現実的なんです。一つの関数には複数の出口が存在することがあります。しかし、入力は1つだけです。したがって、「足し算」は入力のところだけでなければならない。
 
sergeev:

おいおい、そんなに暑くないだろ!ここでは全ページをカウントしているんだぞ! :)

遅ればせながら、あなたの願いはあなたの声でした ;)

また,関数からの入出力イベントをどのように処理するかは,別の問題です。

 
IgorM:

遅ればせながら、あなたの願いはあなたの声でした ;)

枝はいつでも埋められる。そして、これは願望ではありません。

また、関数からの入出力イベントをどのように処理するかは、別の問題です。

ちょっと理解できない。ここでマトリクスがどのように適合するのか、指で説明できますか?

関数をグラフ(俗に言うツリー)にすることです。しかし、明確な時系列での呼び出し順と、呼び出されたものの識別で。1つの同じ関数が、startと initの 両方から呼び出されることがあります。これが、私たちが修正すべき点です。

(MQL5で開発しているため、グラフにクラスを使用しています。)

 
sergeev:

グラフ(俗に言うツリー)。

木は、グラフの特殊なケースです。