При написании индикатора, который использует краткую форму вызова функции OnCalculate(), можно упустить то обстоятельство, что индикатор может рассчитываться не только на ценовых данных, но и на данных другого индикатора (встроенного или пользовательского - не имеет значения). Вы хотите улучшить индикатор, чтобы он правильно считался не только на ценовых данных, но и значениях другого индикатора? В этой статье мы по шагам пройдем все необходимые этапы такой модификации и выведем дополнительные полезные правила для правильного написания индикатора.
反論しない。
しかし、このように
どうせ丸め込みがあるのだから、そうすべきなのでしょうか？
デベロッパー
Expert Advisorでティックの処理を誤ってループさせてしまい、その後スタックオーバーフローのクリティカルエラーが 表示されました。
問題は、具体的にどこで何が起こったのか、メッセージに具体的な情報がないことです。
できれば、このような問題（たとえば、呼び出されたメソッドからクラスメソッドを呼び出すなど）をコンパイルの段階でキャッチしたいので、このメッセージの文章を明確にすることを提案します。
実際には何も入っていないそのバッファセルに、iCustom()が任意の値を代入している理由も、どうにも避けられない理由も、私には不明です。
インジケータバッファの 対応するデータ配列のメモリ確保と関係があるのでしょう。
データの出所や真偽を判断することが不可能なiCustom()のこのような操作は、私には許されないと思いますし、ユーザーにとってさらなるリスクを生むことになります。
iCustom()が任意の、実値と矛盾する値をとにかくバッファセルに割り当てる場合。
MT4で実装されているように、これらのセルにEmpty_Valueと等しい値を割り当てないのはなぜですか？
そうすれば、少なくとも彼らの地位は明らかになるはずだ。
デベロッパー
.............................できれば、このような問題（呼び出されたメソッドからクラスメソッドを 呼び出すなど）をコンパイル時にキャッチしたいものです。
私は反対です。コンパイラが異常に複雑になり、その結果、信頼性が低下してしまうのです。
不正な再帰を追跡するのはプログラマー次第である。
しかし、エラーメッセージには、スタックをオーバーフローさせた関数の名前を含めてほしい。
未使用のバッファ値をどのように埋めるかは、作者以外には決められない。Empty_Valueと ありますが、私などは0にしたい、とか。どんな値でも、それで初期化する。
これは正しく、論理的なことです。しかし、問題は、ユーザーが何も記入していない（！）バッファセルに、iCustom()関数が定期的に任意のゴミを記入することです。 そのようなことになっているのでしょうか？
私は反対です。コンパイラが法外に複雑になるため、信頼性が低くなる。
不正な再帰を追跡するのはプログラマー次第です。
しかし、エラーメッセージには、スタックをオーバーフローさせた関数の名前を含めてほしい。
そうですね、メタ情報で作業エンジンを複雑にしない（結局はネイティブの32/64です）ように意図しています。
再帰は、ローカル変数のサイズに直接依存し、プログラム中にそのような場所はほとんどないため、通常は簡単に捕捉することができます。
これは正しく、論理的なことです。しかし、問題は、ユーザが埋めていない（！）バッファセルを、iCustom()関数が勝手にゴミで埋めてしまうことです。 このようなことになっているのでしょうか？
カスタムインジケータがバッファを正しく満たさない場合、このカスタムインジケータは有罪になります。
また、このカスタムインジケーターがiCustomを通じて結果を送信する場合、ユーザーに誤解を与えるため、二重の罪となります。
カスタムインジケータがバッファを正しく満たさない場合、このカスタムインジケータが有罪であることを意味します。
また、このカスタムインジケーターがiCustomを通じて結果を出す場合、ユーザーに誤解を与えるため、二重に有罪になります。
カスタム・インジケータがバッファを正しく満たさない場合、その原因はこのカスタム・インジケータにあります。
また、このカスタムインジケーターがiCustomを通じて結果を送信する場合、ユーザーに誤解を与えるため、二重に有罪になります。
まだ理解できないのですが、プログラムを効率的にするだけでなく、便利にすることを妨げるものは何ですか？私の記憶が正しければ、5でインジケータ・バッファの初期化を 内蔵していない理由は、速度を最適化するためです。この場合、開発者は、以前はカーネルが行っていた初期化文字列（「ゼロ」）を自分でコーディングしなければならない。だから、結果的に効率は上がらないし、使い勝手も悪くなるようです。でも、せっかくこういう形にしたのだから、オプションにしたらどうだろう。つまり、もう一つ#propertyを導入して、バッファを自動的に初期化するかどうかを指定することができます。
要約すると、すでに一度述べた考えを繰り返すと、MTであるプラットフォームの仕事は、ユーザー（プログラマー）を可能な限り落とし穴から守ることである、ということです。
これは正しく、論理的なことです。しかし、問題は、ユーザーが何も記入していない（！）バッファセルに、iCustom()関数が定期的に勝手な判断で任意のゴミを記入することです。 こんなはずでは？
実はこれ、「配列の初期 化はユーザーの判断で」という共通ルールなんです。初期化されていない配列は、その配列に割り当てられたメモリからランダムな値を含んでいます。 ユーザには，不必要に配列を初期化しない正当な理由（例えば，時間の節約）があるかもしれません．本当の情報がある前に、そのゴミを読んで「食べる」必要がないと確信したとき、私はこの方法で時間を節約することがあります。
MQ側に悪意があるとは思えません。むしろ、「予防的に」プログラムを遅らせるようになったら、反対です。