mql5言語の特徴、微妙なニュアンスとテクニック - ページ 191

[traveller00]

template <typename T>
void func(const T &IntOrArray) {} 

void OnStart()
{
  int a=0;
  char b[3]={};
  func(a);
  func(b);	//'b' - parameter conversion not allowed
}

このエラーを投げるのはバグなのかチップなのか？

C++はこれをよく食べてくれる。そして、MQLの配列は、独自の配列を持っています。つまり、ある種のstd::arrayもこの構成で扱うことができるのです。

[fxsaber]

traveller00:

このエラーを投げるのはバグなのか、不具合なのか？

バグではありません。テンプレートの過多は、それだけで効果があります。

[Andrey Khatimlianskii]

ある楽器の履歴がないことをすぐに知る方法はありますか（ローカルでもサーバーでも）？

CopyXXXのリクエストは、データを取得するのに30秒待ち、多数の機器を通過するのに不当に長い時間がかかります。

一部のツールでは、Bidがあるかどうか（空であるかどうか）を確認するのに役立ちますが、すべてのツールでそうではありません。

ICMarkets-MT5、ツールWheat_U0 にてご確認いただけます。

[Vladimir Pastushak]

Andrey Khatimlianskii:

ある楽器の履歴がないことをすぐに知る方法はありますか（ローカルでもサーバーでも）？

CopyXXXのリクエストはいずれもデータを取得するのに30秒待ち、多数の楽器を調べるのに不当に時間がかかる。

一部のツールでは、Bidがあるかどうか（空であるかどうか）を確認するのに役立ちますが、すべてのツールでそうではありません。

ICMarkets-MT5のWheat_U0という インストルメントで確認できます。

これについてはすでに何度も書かれていますが、ここではまず、https://www.mql5.com/ru/forum/285631/page35#comment_9431199。

あるいは、これらのシンボルのAskとBidは0である。

[Igor Makanu]

Andrey Khatimlianskii:

ある楽器の履歴がないことをすぐに知る方法はありますか（ローカルでもサーバーでも）？

CopyXXXのリクエストはいずれもデータを取得するのに30秒待ち、多数の機器を通過するのに不当に時間がかかる。

一部のツールでは、Bidがあるかどうか（空であるかどうか）を確認するのに役立ちますが、すべてのツールでそうではありません。

ICMarkets-MT5、インストルメントWheat_U0にて ご確認いただけます。

インジケータはCopyXXXの結果を待ちません。

CopyXXXを 処理し、EAからこのインジケータを呼び出す ために、インジケータ内のタイマーのオプションとして

[Andrey Khatimlianskii]

Vladimir Pastushak:

これは何度も書かれていますが、私が最初に見つけたのはこれです https://www.mql5.com/ru/forum/285631/page35#comment_9431199

これらの記号の変種として Ask and Bid == 0

一度に書くBidは0枚程度、0枚でないこともある。

イゴール・マカヌ：

インジケータはCopyXXXの結果を待ちません。

CopyXXXを 処理し、EAからこのインジケータを呼び出す ためのインジケータにタイマーのバリエーションがある

それはいいアイデアですね。ありがとうございます、やってみます。

[Vasiliy_Saharov]

fxsaber:

その理由は、こうです。最初のOrderSendの後、成行注文が現れ、その実行前に新しいティックが来ると、まだポジションはなく、2回目のOrderSendが行われます。

このため、一見正常に見えるMT5のパターンも正常に 動作せず、結果としてcodobaseにあるMT5 Expert Advisorのほとんどが 動作しなくなります。同時に、ほぼ同じMT4テンプレートも 問題なく動作し続けます。

PositionTotalの一見良いアイデアは、MT5では成行注文のOrdersTotalも分析する必要があるため、やや影が薄くなっています。

気をつけよう!

ご指摘ありがとうございます。そんな思いがありました。でも、いざEAを書くとなると、サーバーに送られるリクエストをチェックするのは意味があるのかなと。仮定の話として、正しく記述されていますが、実際にはサーバーはリクエストに素早く反応し、そのような状態はほとんどの場合（99％だと思います）起こりません。しかし、アルゴリズムの速度は毎回低下します。どちらがより重要だと思いますか？

[Andrey Khatimlianskii]

Vasiliy_Saharov:

ご指摘ありがとうございます。心に刻みました。しかし、今回Expert Advisorを書くことになり、サーバーに送られるリクエストをチェックすることに意味があるのかどうか考えてみました。仮定の話として、正しく記述されていますが、実際にはサーバーはリクエストに素早く反応し、そのような状態はほとんどの場合（99％だと思います）起こりません。しかし、アルゴリズムの速度は毎回低下します。どちらがより重要だと思いますか？

0.1ロットではなく2ロットで一度市場に参入すれば、答えは一目瞭然です）

[Vasiliy_Saharov]

Andrey Khatimlianskii:

0.1ロットではなく2ロットで一度市場に参入すれば、答えは一目瞭然です）

0.1ロットを作るアルゴリズムがあるとすれば、0.1を2回作る確率があり、この確率はゼロになる傾向があり、3回は、無理だと思います。20回はおろか何しろアプリケーションの話ですからね。経験則では、サーバーはおそらく10minsecの限界で応答する（正しいかどうか？）2回目の取引をつかむ確率は、どの程度だとお考えですか？このチェックはご自身でされているのでしょうか？サーバーの応答が遅くなることはありませんか？

[traveller00]

Vasiliy_Saharov:

0.1ロットを結論付けるアルゴリズムがあるとすれば、0.1が2回、この確率がゼロになる傾向があると思うので、3回というのは不可能だと思います。20回はおろか何しろアプリケーションの話ですからね。経験則では、サーバーはおそらく10minsecの限界で応答する（正しいかどうか？）2回目の取引をつかむ確率は、どの程度だとお考えですか？このチェックはご自身でされているのでしょうか？サーバーの応答が遅くなることはありませんか？

統計より：1日約200～300件の取引がある。通常のチェックでも、特に難しいチェックをしなくても、平均して週に2～3回はダブルロット開封をキャッチしていました。確率を計算し、そのような確率を受け入れる必要があるか、または準備ができているかを評価する。個人的には、チェックを最大にしました。