double iMACDMQL4(string symbol,
int tf,
int fast_ema_period,
int slow_ema_period,
int signal_period,
int price,
int mode,
int shift)
{
ENUM_TIMEFRAMES timeframe=TFMigrate(tf);
ENUM_APPLIED_PRICE applied_price=PriceMigrate(price);
int handle=iMACD(symbol,timeframe,
fast_ema_period,slow_ema_period,
signal_period,applied_price);
if(handle<0)
{
Print("Объект iMACD не создан: Ошибка ",GetLastError());
return(-1);
}
elsereturn(CopyBufferMQL4(handle,mode,shift));
}
...異なるパラメータで呼び出しを開始し、インジケータを乗算し、すべてのハンドルを失い、そしてブレーキとメモリ消費について疑問に思う。
正直なところ、ハンドルがMetaTraderの舞台裏に保存されているのであれば、どのようにしてハンドルが失われるのか、私には理解できません。
p.s.一般的に、この記事の著者が議論に参加し、MT5でインジケータハンドルを使用する際のビジョンについていくつかの点を説明しましょう。
正直なところ、MetaTraderの裏側でハンドルが記憶されている場合、どうしてハンドルが失われるのか理解できませんでした。
コード品質に対するこのアプローチで、もう疑問はなくなりました。
おっしゃる意味がよくわかりません。私が理解する限り、ヘンドルはどこにもクローズされません（IndicatorReleaseへの呼び出しは ありません）。iMACDのような、ヘンドルを作成する標準的な関数が常に呼び出されています：
明らかに、ここでのゲーム全体は、iMACDや同様の関数が以前に返されたハンドルを自分自身の中にキャッシュするという事実に基づいています。
OnInit()で1つのハンドルを作成し、インジケータ・データへのアクセスはCopyXXXX関数を通して取得する。MQL4スタイルのハンドルの再作成を使用すると、それは非常に間違っており、大失敗となる。しかしその過程で、MQL5カーネルは非常に賢く（明らかに同一ハンドルの内部キャッシュが存在する）、ハンドルの再作成を許可しないことが判明した。
副次的な効果として、MQL5カーネルは非常にうまく設計されているため、MQL5が流行に流されない方法で動作することを可能にしている。
類似点は見当たらない。
どちらの記事もMQL5で最も単純なMQL4スタイルのバリアントを書くという同じことを提供している。比較する
トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム
記事「トレーダーのためのライフハック：インジケータからファーストフードを作る」のディスカッション
Vasiliy Sokolov, 2018.01.25 16:05
そしてこれ
実は同じことです。
存在すべきでしょうか？記事のタイトル（というかその説明）には、明らかにインジケーターについてのみ書かれていると思うのですが？
タイトルから判断して、あってはならない。しかし、この記事は時系列を使ったMQL4スタイルの作業に触れている。そしてそれなしでは不完全な解決策を得ることになる。MQL4ではほとんどの人が "High[i]"を使っている。しかもその実装は簡単に見つけることができる。
残念ながら、MQLは任意の数のパラメータを持つ関数をサポートしていないため、iCustomを "MT4と同じように "実装することはできません。
MT4のスタイルを完全にエミュレートした本格的なエンジン全体を1つの記事で書くことは不可能だと思います。トピックは、MQL4スタイルでインジケータを操作すること、と明記されています（記事のタイトルがトピックを反映しておらず、紛らわしいのが残念です）。
MQL4スタイルはまだ概念であるが、構文に明確に準拠しているわけではない。
MQL4スタイルでハンドルの再作成を行うと、メモリが消費されてしまう。
だからこそ、MQL4のスタイルで 正しく行えるのに、なぜ間違った作業を実装したのかという疑問が生じるのだ。
MQL5は賢くはない。そうでなければ、どんな偶発的なエラーも不幸な結果を招くだろう。しかし、性能測定が示すように、フールプルーフ・プロテクションは性能に不具合が生じるように設計されている。そのため、「ハンドルの再作成」をMQL5ラッパーに移し、（OOP能力のごく一部を）ユーザーの目から隠す必要があるのだ。
...しかし、性能測定が示すように、フールプルーフは性能の落ち込みがあるような方法で行われている．
それは興味深いね。速度を測定して、その結果をここに投稿するよ。
最もシンプルなブランクで測定した。
オーバーヘッドは約3倍。そう、MetaTrader 5はキャッシュされたハンドルを見つけるのにかなりの時間がかかるのだ。
MACDの MQL4スタイルEAショート」に似たEAで、2つだけでなく、3つ、4つ、5つのインジケーターを扱うことができます。この文脈では、「インジケータ」とは（MACDを例にして）異なるパラメータを持つインジケータを意味しますが、それぞれ1つのシンボルです。
MACD MQL4スタイルのEAが 追加でグラフィックサブシステムにアクセスしている ことに気づいたので、前の投稿を削除した：
つまり、行ったテストが誤っていたのです。コメント関数を コメントした後、パフォーマンスはほぼ同じになりました：
結論：MetaTrader 5はまだ効果的に以前に作成されたキャッシュを見つけ、提案されたコードスタイルを使用することが可能です。
しかし、パフォーマンス測定が示すように、フールプルーフプロテクションはパフォーマンス障害が発生するように作られています。そのため、「ハンドルの再作成」をMQL5ラッパーに移行し、（OOP機能のごく一部を）ユーザーの目から隠す必要があるのだ。
MetaTrader 5はキャッシュされたハンドルを見つけるのにかなりの時間を必要とします。
ユーザーが一般的な方法でこのプロセスをスピードアップできる確実性はありません。明らかに、オーバーヘッドはハッシュ関数の計算に費やされます。
このような一般的な形式のインジケータ・ハッシュ関数の1つの変形が、ここに 投稿されている。
そこでは性能は気にしていなかったが、ハッシュ関数の入力がMqlParam-valueの配列でなければならないことは明らかだった。そしてこれは、遅い文字列フィールドがあるという事実を考慮すると、高速には動作しない。
したがって、MT5に組み込まれているものよりもはるかに高速なユニバーサル・インジケータの高速ハッシュ関数を書くことは、オープン・タスクである。しかし、私はインジケーターをどこからか呼び出すことには断固反対です。だから、この問題を理解しようとも思わない。
スマートなMQL5について、もう一つ考えていることがある。多くのExpert Advisorでは、各バーで同じインジケータが呼び出されますが、入力パラメータは異なります。MQL5は時間の経過とともに不要なハンドルを「撃つ」。しかし、これは普遍的な解決策です。そしてExpert Advisorでは、作者はこの責任を自分で負うことができ、自分でハンドルを殺すことができます。100のバーで100のハンドルの荷物を運ぶのは、計算資源と メモリの点で超無駄であることは明らかです。しかし、同じコドベースのEAで、このようにハンドルに釘を刺すようなEAは見たことがない。すべてが「MQL5の賢さ」に委ねられているため、作者はまったく賢くないことを余儀なくされている。
しかし、繰り返すが、インジケーターとバーは悪である。
ユーザーが一般的な方法でこのプロセスを高速化できる確証はない。明らかに、オーバーヘッドはハッシュ関数の計算に費やされる。
このような一般的な形式のインジケータ・ハッシュ関数の1つの変形が、ここに 掲載されている。
さて、あなたは1つの記事で多くの情報を読者に投げかけたかったのだろう。しかし、あなたの方法に関しては、それは真正面からの解決策である。そして性能を比較した？