私はGUIを完全にアセンブラでコーディングしていました。しかし、アセンブラではポインタを扱うことができ、Cではポインタを扱うことができます。もちろん、Windowsの基本はOOPではありませんが、MQLの話をすると、ネイティブな方法でボイドポインタをサポートしていないので、if then elseだけで複雑なGUIをコーディングすることはできませんし、少なくともパフォーマンスを大きく損なわずに使用できるような結果ではありません。
5)最後に、MQ5はまだ顧客ティックでバックテストを実行 できません :( <Edited by moderator as off-topic : this has nothing to do with mql5 but with MT5> <Edited by moderator as off-topic : this has nothing to do with mql5 but with MT5>.
私はプログラマーとしてGUIのプログラミングをすることが多かったです。GUIは、ifとelseで複数の方向に通信する必要があるため、完全なGUIをコーディングすることは不可能です。多くの記述が必要になり、コードが読めなくなるし、結局は遅すぎてゴールにたどり着けなくなる。事実です。
私は、あなたが間違っていることを証明するために、手続き型言語でGUIを構築するつもりはありません。でも、間違いなく作れます。
ところで、OOPでは読めないコードやずっと遅いコードを書くことも簡単で、ご存知のようにMetaquotesStandard Libraryは その良い証拠です。
...
CPUがOOPを知らないという事情から、もちろんポインタや複雑な配列を使うだけですべてをコード化することは可能です。でも、そんなのバカバカしい。また、私のスクリーン・コンテンツをフィルムにリアルタイムで描き、それを壁に投影するプロジェクターを1万人雇うこともできます。これもゴールなのでしょうか？
Windowsオペレーティングシステムが良いGUIを提供していることに同意しますか？私の知る限り、それはCで書かれています。OOPではなく手続き型言語です。
複雑なプログラムはOOPでなければ作れないと思ったら大間違いです。むしろ、なぜOOPでコーディングした方が良いのかを説明すべきです。
ええと、さあ;)そうでもないよ;)もし何かネイティブなものが変な仕事をするのであれば、そのポインタがありますが、MQLには制限があるのです。しかし、MQLには制限があります。
私は、OOPがコーディングの近道であることを強く疑っています。
Windowsオペレーティングシステムが優れたGUIを提供していることに同意しますか？私の知る限り、それはCで書かれています。OOPではなく手続き型言語です。
もし、あなたが複雑なプログラムはOOPでなければ作れないと思っているなら、それは間違いです。むしろ、なぜOOPでコーディングした方が良いのかを説明すべきです。
私はGUIを完全にアセンブラでコーディングしていました。もちろんWindowsの基本はOOPではありませんが、MQLはボイドポインタをネイティブにサポートしていないため、if then elseだけで複雑なGUIをコーディングすることはできません。
そしてこの答えには、なぜOOPの方が良いのかという疑問も含まれています。しかし、「良い」というのはまだ間違った表現です。OOPメソッドは、ポインタの使い方を実装していますが、ポインタの扱いを強制するものではありません。内部的には、OOPは関数や 変数のポインタに多次元配列を使って実現されています。このようなコードを書こうとすることは、車輪を再発明するのと同じことで、決して目の前にある車輪のようにスムーズに転がることはないのです。
私はGUIを完全にアセンブラでコーディングしていました。しかし、アセンブラではポインタを扱うことができ、Cではポインタを扱うことができます。もちろん、Windowsの基本はOOPではありませんが、MQLの話をすると、ネイティブな方法でボイドポインタをサポートしていないので、if then elseだけで複雑なGUIをコーディングすることはできませんし、少なくともパフォーマンスを大きく損なわずに使用できるような結果ではありません。
そしてこの答えには、なぜOOPの方が良いのかという疑問も含まれています。しかし、「良い」というのはまだ間違った表現です。OOPメソッドは、ポインタの使い方を実装していますが、ポインタの扱いを強制するものではありません。内部的には、OOPは関数や変数のポインタに多次元配列を使って実現されています。このようなコードを書こうとすることは、車輪を再発明するのと同じことで、決して目の前にある車輪のようにスムーズに転がることはないのです。
私の少ない（！）経験による個人的な好みに過ぎません。
1) Javaは、99%の時間、関数の 名前が何なのか、存在するのかしないのか、自分でコーディングしなければならないのか、わからないまま検索していたので、好きではありません．
2) C++は、mq4やPerlのようなスクリプト言語よりも多くのことを書かなければならないので、あまり好きではありません。
3) C++が嫌いな理由は、他人のコードを理解するために、ファイルからファイルへ飛び、2、3行の関数しか見つからず、何が、どのようにs.th.を計算しているかを見つけるのが本当に難しくなるからです。もちろん、"stopを計算する "というような説明もありますが、calc.-procedureは異なるファイルの複数の関数に分割されているのと同じです。
4) enumとenum変数の配列は絶対に必要です。実際のオブジェクトを想像してコーディングする必要はないのです。GUIは、再利用を容易にするためにオブジェクトとしてコード化できる他の多くのものから構成されているので、別の問題かもしれません。しかし、EAには何種類のオブジェクトが必要でしょうか？ポジションに1つですか？もし、多くの異なる「オブジェクト」（GUI）があれば、それは助けになるかもしれませんが、ここではそれを見かけません。
5)最後に、MQ5はまだ顧客ティックでバックテストを実行 できません :( <Edited by moderator as off-topic : this has nothing to do with mql5 but with MT5> <Edited by moderator as off-topic : this has nothing to do with mql5 but with MT5>.
アセンブルのコーディングをしている人は、ハードウェアの仕組みに精通しているんだろうなあと思います。
今はもうコーディングしていませんが、昔は本当によくやっていました。Intel 80x86チップでは、ビジュアルパフォーマンスの観点から真のエッジを達成するための唯一のチャンスだったのです。もちろん、その基本的な知識は、もう詳細には必要ないとしても、絶対に逃したくないものです。でも、自分のコードが最終的にどうなるのか、それを実行速度という観点からどう利用すればいいのかは、常にわかっているはずです。
そう、"古き良き "時代なのです;)...でも、変数もなければ、関数も ない、ifもelseもない、レジスタとスタックと割り込みとメモリアドレスだけ。狂気の沙汰だ :)
OOPは、コードを再利用可能な小さなパーツに分割するためのツールです。しかし、最も優れているのはテンプレートです。この機能により、コードを単純化することができる。その最たる例が配列クラスです。Javaでは、型のためのクラスを作らなければ なりません。C++やMql5では、それを1つのクラスにして、冗長なコードを減らし、プリミティブとオブジェクトを混在させたときのいくつかの問題を回避することができるのです。
追記：ASMについてですが、これは古いものです。プロテクトモードコンパイラが登場する前は、制限をオーバーパスするのが面白くて使っていました。64Kセグメントとセレクタは、当時のコーダーの悪夢でした。間違った場所に書き込むたびにコンピュータをリブートしなければならなかった:)