2030年のメタトレーダーXをどのように捉えていますか? - ページ 2

 
Igor Makanu:
...

異なるチャート上で動作するEA間でデータを交換する方法があります。

すでに実装しており、うまくいっています。多重継承の意味を理解している人なら、誰でもできるはずです。そうでなければ、彼が知っていることは残念なことです。

 
Igor Makanu:

端末のグローバル変数に バイトの配列を送信する標準的な関数(ただし、変換方法に関する質問が少ないように int 配列が望ましい)と、それに応じて、この配列を別の Expert Advisor で読み取ることができる逆関数です。

グローバル変数は、データを交換するのに十分ではありません - 変数名のための大きなフィールドとデータのための小さなフィールドがあり、それは逆が必要です;)

SZZ:決定グラフを解析するための多くの例がネット上にあり、主にインターフェイスのために、柔軟なコード構造を達成し、インターフェイスはどこにでもある、MQLではありません(。

全く同感です。端末のグローバル変数がラメになっている。しかし、WCFのように配列ではなく、クラスインスタンスを保存する必要があります。私の時は、この機能に本当に衝撃を受けたんです。ネットワーク上でバイトストリームをさばく代わりに、クラスインスタンスを送るだけで、バイナリで送れば、すべてのことが.NETで迅速に処理されるのです。

うーん、キーボードを押しているうちに、こんなリブーを作ってみようかと思いつきました...。

---

ディシジョングラフやインターフェースについては、私は単に遭遇したことがないだけで、プログラミングの世界は広大です )) 。

 
Реter Konow:

すでに実装しており、動作しています。多重継承の意味を理解している人なら、誰でもできるはずです。そうでなければ、彼の知識は何の価値もない。

そして、安っぽい華やかさもなく?

 
Реter Konow:

すでに実装しており、動作しています。

и?

KBには以前から既成のソリューションがありましたが、あなた自身のソリューションも追加されたのですか? それともただ通りすがりですか?

 
Igor Makanu:

и?

KBには以前から既成のソリューションがありましたが、あなた自身のソリューションも追加されたのですか? それとも、ただ通りすがりですか?

多重継承の話からすると、空...

 
Alexey Volchanskiy:

WCFのように、クラスインスタンス

複雑なソリューションを用意しても、大量に使われることはないでしょう。配列の読み書きは誰でもできますから、もっと複雑なものが必要なら、需要はないでしょう。 上に書いたように、KBにはデータ交換 用の適切なソリューションがありますが、GlobalArrayWrite(string name, int out[]) と GlobalArrayRead(string name , int &in[]) - それだけでユーザーは必要なくなる、と私は思っています。

 
Alexey Volchanskiy:

そして、華やかさもなく?

リソース異なるチャートに配置したい両方のEAプログラム(またはインジケータ、またはEAとインジケータ)で、いくつかのタイプの配列でユニオンを宣言する。各プログラムで、反対側のアドレスを文字列変数(フォルダ、サブフォルダ、プログラム名)に書き込むのです。通信には2つの機能を使います。1つ目の機能はメッセージを読むことで、2つ目の機能はメッセージを書くことです。両プログラムとも、タイマーの周波数で関数が呼び出されます。

各プログラムの機能は、転送するデータをすべて文字列変数に書き込む必要があります。そして、タイマー関数の最後にメッセージパッシング関数が呼ば れ、収集した文字列がリソースに保存されることになる。次のタイマー周期で、別のチャート上の別のプログラムが、他のプログラムのアドレスにあるリソースの読み取り関数を呼び出し、メッセージを解凍します。そして、そのリソースに必要なデータを書き込むだけで、同じように最初のプログラムへのメッセージを構成し、渡すことができます。

 
Alexey Volchanskiy:

疑問に思ったのですが、私はFXを始めて約13年、2006年にMT4で始めました。この話題になったのは、当時付き合っていた彼女に「ターミナルを理解したい」と言われ、嬉々としてMQL4というC言語っぽいものを発見し、ハマったからです。思い起こせば、ターミナルで英語を使って仕事をしていた私は、てっきり欧米の開発だと思い込んでいました。カザンの人が作ったと知った時は、認知的不協和が起きました))

そうして13年が経過し、MT*端末の発展にはいくつかの段階を踏むことができます。

1.MT5開発の始まり、2009年だったと思います。MT5の開発が始まったのは2009年だったと思いますが、その頃、alpのフォーラムをよく訪れていて、Renatがプロパガンダで訪れて、FXではネッティングスキームは商業的に死んでいると主張していたことを今でも覚えています。

2. 私にとって非常に重要なマイルストーン、2013年初頭、新しいMT4ビルド> 600のリリース。C++のような構造体やクラス、新しい定義もあって、わくわくしました。ついに全てのバグが修正され、コピーペースト時にエディターがクラッシュすることがなくなり、その他のバグも修正されました。 以前からストラテジーはすべてC++へのブリッジを経由してC#で書いていたのですが、シャッフルではなく普通に動作するようになったので、MQL4への移植を開始しました。

3.こちらの年号は覚えていませんが、もしかしたら2016年かもしれません?訂正してください。私の考えは、MT5のヘッジバージョンを使用することでした。

4.年号も思い出せない、2018年頃?単一コンパイラで、MT5で1つのマルチプラットフォームプロジェクトを書くことが可能です。それ以来、ずっと自分のために書いているんです。この機会をお客様に提供すると、90%のお客様がすぐに受け入れてくれますが、絶対に全員がこのことを知らないでいます。マルチプラットフォームには、fxsaberのMT4Orders libuをお勧めします。

5.MT5は常に進化しているので、これはとても嬉しいごった煮です。

13年間のプラットフォーム開発の概略を説明しましたが、あと10年後にはどうなっているのでしょうか。もしかしたら、今後の展開にファンタジーが反映されるかもしれませんね ))

それはまた別の話ですが...。10人の女友達に一度に土下座して、端末を調べてくれと懇願されたこともある...。私は彼らにこう答えた。「恥を知れ、私は自由人ではない、すでに50人のガールフレンドを指導している、サンクトペテルブルクには3部屋のアパートしかない、そして時間的余裕はない、昼夜チェチェンでおしっこをしなければならない...」と。

そして、MTは今も、そしてこれからも。

 
Igor Makanu:

и?

KBには以前から既成のソリューションがありましたが、あなた自身のソリューションも追加されたのですか? それともただ通りすがりですか?

では、なぜ30代で待っているのですか?すでにあるのなら...
 
Igor Makanu:

複雑なソリューションを持つことはできません、そこに大衆はありません、誰でも配列を読み書きすることができます、より複雑な何かが必要とされない場合。 私は上に書いたように、KBのデータ交換のための良いソリューションがありますが、イモー、GlobalArrayWrite(文字列名、int out[]) と GlobalArrayRead(string name , int &in[]) - それはすべて、ユーザーが必要としません。

見てください、ファイル操作だって昔からできるんです

uintFileWriteStruct()
intfile_handle,//ファイルハンドル
const void&struct_object,// オブジェクトの参照
intsize=-1// 書き込みサイズ(バイト)
);


単純な型のストリームをパースするよりも、構造体やクラスオブジェクトを 読み書きする方がずっと便利です。年齢とともに怠け者になったのかも?そうですね、キーボードをあまり叩かずに、いろいろなことをする方がいいですね ))