グラフィカルモードでMQLのGUIを作成する。 - ページ 11

 
Renat Fatkhullin:

今でもそうなのか?

相互運用の可能性は、すべて以前からあったものです。DLL全般のサポートは2004年に導入されました。

私たちの言語は常に進化し、よりパワフルで機能的になっています。そして、そのエコシステムは誰よりも強力なものです。

よくぞ言ってくれました。そして、これからもっともっと良くなっていくことでしょう硬直性がないことが、チームの最大の特徴であり、開発者の成功でもあるのです))

 
Алексей Барбашин:

よくぞ言ってくれました。そして、これからもっともっと良くなっていくことでしょう硬直性がないことが、チームの最大の特徴であり、開発者の成功でもあるのです))

私たちの党は、私たちの舵取り役 !硬直化から脱却し、党利党略に走るカモン!!!!

 
Алексей Барбашин:

よくぞ言ってくれました。そして、これからもっともっと良くなっていくことでしょう硬直性がないことが、チームの最大の特徴であり、開発者の成功でもあるのです))

特に、9月に32ビット版を凍結し、64ビットプラットフォーム版のみをサポートすることになれば、そうなります。

現在、一部のシステム関数をMQL5プログラムに移植したコンパイラの本格的なバージョンアップを準備しており、これによりオプティマイザが劇的に改善され、MQL5プログラムの結果コードが加速される予定です。

C++との比較のために、完全な性能ベンチマークをソースコードと一緒に公開し、誰でも自分で確認できるようにする予定です。

 
Renat Fatkhullin:

今でもそうなのか?

相互運用の可能性は、すべて以前からあったものです。DLL全般のサポートは 2004年に導入されました。

私たちの言語は常に進化し、よりパワフルで機能的になっています。そして、そのエコシステムは誰よりも強力なものです。

これは、80年代後半のボーランドC++の、申し訳程度のレベルです。イベント、コリボックス、COMオブジェクトとして実装された完全な機能のAPIを提供する - 端末は貴重なものでしょう。
 
Yuriy Asaulenko:
80年代後半のBorland C++のようなレベルで、すみません、どこかです。イベントやコールベル、COMオブジェクトとして実装可能なフル機能のAPIを提供してください - 端末は貴重でしょう。

なぜ許すのか?絶賛するのはやめてください。

私たちは強力なアプリケーション言語を持っており、私たちが構築したエコシステムによって、正しい方向に進んでいることを示しました。ユーザー、開発者、そして私たちを守る。

これはビジネスであって、ポピュリストのためのプラットフォームではありません。

 
Yuriy Asaulenko:
これは、申し訳ないが、80年代後半のボーランドC++のようなレベルだ。イベント、コリボックス、COMオブジェクトとして実装された、完全な機能を持つAPIを提供してください。

すぐに時代遅れになってしまいますが、端末のCOMインターフェイスとしては格好のものでしょう。

ただ、実際の時間には合わないんですよね :-(.

 
Renat Fatkhullin:

なぜ許すのか?絶賛するのはやめてください。

私たちは、構築されたエコシステムによって、正しい方向に進んでいることが示されたアプリケーション言語を持っています。ユーザー、開発者、そして私たちを守る。

これはビジネスであって、ポピュリストのためのプラットフォームではありません。

ご回答ありがとうございました。
 
Maxim Kuznetsov:

端末用のCOMインターフェースは、急速に陳腐化しつつありますが、クールだと思います。

でも、リアルタイムには合わないんですよね :-(.

でも、VinAPI風DLLは最新のものです)。
 
Renat Fatkhullin:

特に、9月に32ビット版を凍結し、64ビット版のみの対応とする予定です。

現在、コンパイラの本格的なアップグレードを準備しており、一部のシステム関数をMQL5プログラムに移行することで、オプティマイザが劇的に改善され、MQL5プログラムの結果コードが高速化される予定です。

C++との比較のために、完全な性能ベンチマークをソースコードと一緒に公開し、誰でも自分で確認できるようにする予定です。

Renat、x32を無効にする前に、あなたのホスト名でx64を実行することを確認してください。もし、必要ないのであれば、私にも伝えてください。そうすれば、私たちは選択肢を考える時間を持つことができます。

 
Alexey Volchanskiy:

そして、女性的な感情を抜きにして、数字で勝負しよう。このひどいボトルネックを処理するために、CPUはどれだけの負荷をかけているのでしょうか?どうせWindowsではCLRエンジンが常時稼働していますし、私たちだけが使っているわけではありません。まず何よりも、それを使うのは風そのものである。

.net,#というのは全体的に遅くて不器用な機械で、マネージドコードとネイティブコードをどうやって比較するのでしょうか?
"どうせCLRマシンは常に風を切って走っているのだから、我々だけが使っているわけではないのだ。使うのは主に風そのもの」、共感します。メモリを見てみると、システム(Linux)による私のメモリ消費量は以下の通りです。

MiB Mem : 合計 2998.9, 2411.2 空き, 38.9 使用, 548.8 バフ/キャッシュ

38.9MBと、仮想マシンを 持つWindowsでは実現不可能であり、しかもスワップが使われていない状態です。

MiB Swap: 合計 8192.0, 空き 8192.0, 使用 0.0, 空きメモリ 2474.6

そして、あなたは感情なしで伝えることができます - C#のフォームがC + + / FLTKでより優れているどのような方法で、例えば、フォームエディタがあります - FLUID、私の意見では必要ありませんが、単純なウィンドウ - ダースまたは2ダース文字列を?