class CiCustom : public CIndicator : public CDoubleBuffer
пользуется включением class CSeries : public CArrayObj который в свою очередь
пользуется включением class CArrayDouble : public CArray и
class CArrayObj : public CArray ну и конечно куда как без
включения class CArray : public CObject который включает
class CObject и #include "StdLibErr.mqh"
忘れてはいけないのは、非常に優秀なインライナーが動いていて、細かい機能をたくさん排出しているので、スピードが落ちることはないのです。
また、vtableを介した仮想関数の 呼び出しは、ほとんどの場合、直接呼び出しに最適化されています。これはオプティマイザーの有効な手法の一つです。これは、複数のインライン化と相まって、複雑な複数レベルの呼び出しをほぼ完全に排除し、コードを平坦に見せることができるのです。
忘れてはいけないのは、非常に優秀なインライナーが動いていて、細かい機能をたくさん排出しているので、スピードが落ちることはないのです。
また、vtableを介した仮想関数の 呼び出しは、ほとんどの場合、直接呼び出しに最適化されています。これはオプティマイザーの有効な手法の一つです。そのため、複数のインライン化と相まって、複雑な複数レベルの呼び出しをほぼ完全に排除し、コードをフラットに見せることができるのです。
:) 面白いですね。また、誰もコンパイラが完璧にコードを最適化することに異議を唱えていません。私はただ、私がSBの前に伏せ字にならない理由を友人に示しただけです。
よし、例題を使おう。
は，実際には単純な標準関数で置き換えられる
CopyBuffer(...);アートのためのアートがあるのです。そして、何かをする各要素についてです（残りは、ご理解の通り、最終的な要素が機能するために書かれています）。
そうですね、汎用性があるのもそうですし、コードがしっかり構造化されているのもそうです（解析用のサンプルと言われるかもしれませんが）。
しかし、その要点は何でしょうか？ポイントは、このライブラリは主にMQL5 Wizardのために、そしてOOPのチュートリアルとして必要なものであるということです。
SBの前で倒れない理由を同志に理解してもらうだけです。
はい、はい、もう一度強調しますが、私はあなたのどの主張にも真剣に異論を唱えるものではありません。これに関する議論は、客観的というより宗教的なものでしょう。
個人的には、あなたの例で言うと、最初のコードの方が受け入れやすいと思います。なぜなら、CObjectから始まってCiCustomまでのすべてのインターフェースとインジケータの互換性を提供する、すべてのマルチレベルのインクルージョンがあるからです。
しかし、その一方で、すべての時系列と指標はオンデマンドで作成され、単一のコレクションにスタックされ、すべてのユーザーが利用できるようになっています。また、バッファのコピーは1回で済むので、わざわざこんな面倒なことをする必要があるのだろうかと思います。
ですから、単純なケースでは、もちろん、CopyBuffer()を使う 方がずっと簡単です。
しかし、あるバッファのユーザが何人もいる場合はどうでしょうか？ 私の場合、全員がバッファを要求し、バッファが作成され、残りの全員がそのバッファへの参照を得ることができます。そして、CopyBuffer()を「直接」使用すると、1つのコピーではなく、10つのコピーを持つことになります。さらにCopyBuffer()をうまく使うと、誰がどのバッファを確保したかを追跡できるようになり、あなたが言ったカプセル化と非常に費用対効果が高くなります。
個人的には合理性を重視します。たった一ヶ所のためにOOPでこんな大掛かりなプロットを作るのは意味がないでしょう。もし、多くのユーザーがいるのであれば、OOPのアプローチは正当化されると私は考えています。
そこで、1つのコードでmql4とmql5の両方に対応できるように、例外処理を導入することにしました。
統一の問題が迫っているのです。
2つの言語を統合する場合、#ifdefのような条件付きコンパイルディレクティブは絶対に必要だと考えていました。そうすれば、2つのプラットフォーム間のコードの統一が容易になり、プラットフォーム依存のAPIはコンパイル時に定義されることになります。
残念ながら、そうではありません。テスターはシングルスレッドで、MQL5 Cloud Networkを 使用しないままです。
忘れてはいけないのは、非常に優秀なインライナーが動いていて、細かい機能をたくさん排出しているので、スピードが落ちることはないのです。
また、vtableを介した仮想関数の 呼び出しは、ほとんどの場合、直接呼び出しに最適化されています。これはオプティマイザーの有効な手法の一つです。そのため、多重インライン化と相まって、複雑な多値の呼び出しをほぼ完全に排除し、フラットなコードに仕上げることができます。
ああ...私がプログラムを書くときによく間違えるのが、「関数にはボディが必要だ」ということですが、その理由がわかりました。
インライナーで必要なのは...モジュールをコンパイルするには、関数ヘッダがあれば十分だと思っていたので、不思議に思っていたのですが、そんなことはありませんでした...。ボディが必要...
それはいいことだ。
ああ...私がプログラムを書くときによく間違えるのが、「関数には本体が必要だ」という理由もわかりました。
インライナーで必要なのは...関数のヘッダーだけでモジュールのコンパイルができると思っていたので不思議でしたが、そんなことはありませんでした...。ボディが必要...
正しいのですが、オプティマイザーとは関係ありません。
クラス関数のプロトタイプを 記述した場合、本体は必ず存在する。たとえそれが空っぽでも。
Renat さん、MT4では、チャート上のポジションの可視性をターミナルの一般的なパラメータではなく、各チャートごとに個別に制御することを提案します（MT5で行われたように）。
この件でのSRへの応募は、もう2カ月も眠っているんです。
Renat さん、MT4では、チャート上のポジションの可視性をターミナルの一般的なパラメータではなく、各チャートごとに個別に制御することを提案します（MT5で行われたように）。
この件でのSRへの応募は、もう2カ月も眠っているんです。