Алексей Мокрушин: ドミトリー・フェドセーエフ、不快ではあるが、非常に面白いビデオ挿入。長い間笑ってしまった。あなたが強調した部分を読んで、本当にバカに見えることに気づいた。書き直したのではなく、改善・補足したと言った方が正確だろう。私は、あなたがこのサイトに登場して5年間、あなたの記事をたくさん読んできたし、あなたの知識が私よりはるかに豊富であることを信じて疑わないが、エクスプレス・ライティングに OOPが必要ないという意見には同意できない。グラフィカル・インターフェースを使ったり、1つのEAで複数のTSを組み合わせたり、統計を取ったり、といった複雑なプログラムでは、OOPはプログラムのコードをよりよく構造化するために大いに役立ちますし、デザイン・パターン（私はまだ勉強のごく初期ですが）はOOPの力を何倍にもしてくれます。もちろん、これは小さなEAにOOPを押し込むべきだという意味ではない。もし興味があれば、私がOOPと1つのテンプレートを適用した例と、それによって私の生活がどのように簡素化されたかを説明します。そして、もしそれほど難しくないのであれば、ドミトリーが言った「関数へのポインタがある中で、OOPを使って デリゲートのアナログを作成することは、さらにそうである」という言葉を、例で示してもらえますか？あるいは、どの記事で関数ポインタについての情報を見つけることができますか？よろしくお願いします。
すべてはドキュメントに書いてある。
ドキュメントにはクラスへの参照を取得したり渡したりする方法はありますが、関数への参照は見当たりません。もし難しいことでなければ、リンクを教えてもらえますか？
ヘルプへのリンクをあげました。関数へのポインタの作り方が書いてあります。
ヘルプへのリンクをお見せしました。関数へのポインタを作成する方法が説明されています。
ドミトリー・フェドセーエフ、不快ではあるが、非常に面白いビデオ挿入。長い間笑ってしまった。あなたが強調した部分を読んで、本当にバカに見えることに気づいた。書き直したのではなく、改善・補足したと言った方が正確だろう。私は、あなたがこのサイトに登場して5年間、あなたの記事をたくさん読んできたし、あなたの知識が私よりはるかに豊富であることを信じて疑わないが、エクスプレス・ライティングに OOPが必要ないという意見には同意できない。グラフィカル・インターフェースを使ったり、1つのEAで複数のTSを組み合わせたり、統計を取ったり、といった複雑なプログラムでは、OOPはプログラムのコードをよりよく構造化するために大いに役立ちますし、デザイン・パターン（私はまだ勉強のごく初期ですが）はOOPの力を何倍にもしてくれます。もちろん、これは小さなEAにOOPを押し込むべきだという意味ではない。もし興味があれば、私がOOPと1つのテンプレートを適用した例と、それによって私の生活がどのように簡素化されたかを説明します。そして、もしそれほど難しくないのであれば、ドミトリーが言った「関数へのポインタがある中で、OOPを使って デリゲートのアナログを作成することは、さらにそうである」という言葉を、例で示してもらえますか？あるいは、どの記事で関数ポインタについての情報を見つけることができますか？よろしくお願いします。
関数ポインタ - ヘルプで "typedef "を探してください。C#にはデリゲートがあり、関数ポインタがないのは、言語全体がオブジェクト指向であり、必要なことも不必要なこともすべてオブジェクトを通して行われるからです。
私はOOPを全く否定していません。それどころか、OOPアプリケーション自体が目的になってしまったり、ある規範に従うことが義務になってしまったりしなければ、OOPはとても便利で有用です。
具体的には誰のことですか？特に複数形だし、ここには私たちの多くはいない。単数形だったら、ピーターのことだと思う。でも複数形です。疑問が残る。
なぜファーストネームにしないの？余計な疑問が生じないように。それとも、空気を蹴ることはできないのか？
私は誰かを直接名前で呼ぶつもりはない。複数形は一般化のためだ。自家製の馬鹿げた解決策に基づいて、目利きの立場からわめき散らすのが好きな人は、自分のスレッドで、通り過ぎさせればいい。
私はバザーが好きではないので、誰かを直接名指しで呼ぶつもりはない。複数形は一般化のためだ。自作自演の馬鹿げた解決策に基づいて、目利きの立場からわめき散らすのが好きな人は、自分のスレッドで、見逃してあげてほしい。
そして、あなたが定義する「荒唐無稽」の基準は何ですか？あなたは「自作」のマークアップ言語を作ると主張しているのではないですか？あなたは、記事の中で分かりやすいことを何も言えなかった技術について、「専門家」の立場から判断しているのではないのですか？ディレッタントのクラブへようこそ（笑)。ただ、ここにいるこの分野の人々の中には、（あなたと違って）もっと多くのことを理解している人もいる。だから、「鼻を高くする」必要はない。
もし、あなたが他人の言葉を「黙って」書き捨て、そのコンセプトを開示することなく、それを用意周到な解決策として提示できると考えているのなら、それは甘い考えだ。
例えば私は、マークアップ言語作成の代替ソリューションに興味がある。私の技術は知られているので、他の人がどのようにやっているのか知りたいのです。この問題に対する外部の意見。極めて正当な意見だ。ですから、明確で、理解しやすく、首尾一貫したコンセプトを求めています。あなたは読者に何を求めたのですか？- 文句のつけようのない同意ですか？）
ですから、適切な対応と解決策を議論し、批判を冷静に受け入れてください。）
私はバザーが好きではないので、誰かを直接名指しで呼ぶつもりはない。複数形は一般化のためだ。自作自演の馬鹿げた解決策に基づいて、目利きの立場からわめき散らすのが好きな人は、自分のスレッドで、見逃してあげてほしい。
いいね、それならこの一般化されたリストのトップは君だ。
くだらない質問で申し訳ないのですが、標準のMQLライブラリではできない（あるいはかなり難しい）GUIを構築しようとしているのでしょうか？
また、最初から実現がかなり複雑なようですね。もしかしたら、jQueryスタイルのUI実装を検討した方がいいかもしれませんね？
例えば、簡単なボタンの作成は次のようになります：
もちろん、独自の「オブジェクト・ジェネレーター」などが必要だし、拡張性を持たせて、シャドウ効果やグラデーションなどの「ユーザー定義」オブジェクトをサポートすることも可能だ。
そうすれば、開発者はより簡単にGUIを作ることができるだろう。
また、MT GUI Builderのように、GUIを視覚的に作成し、JSONファイルをエクスポートして、MQL側で高速に実装できるアプリケーションを構築することも可能です。
あくまで、記事を読んでの私の感想です。
もちろん、あなたはあなたのやり方でやってください。
そうだね。私はあなたの選択肢を挙げたが、それらはサードパーティーのフォーマットを解析する必要があるが、その作業の中身は現在行われているものと変わらないだろう。提案されているコンセプトは、すべてをMQLに組み込み、依存関係を持たないというものだ。