MT5で配列の強制クリア?

 

今までMT5を真剣に扱ったことがなかったのに、大きなプロジェクトを一気に移管することになりました。当然ながら難点もあり、そのひとつは配列が常に範囲外になってしまうことです。MT4では、発表後にわざわざアレイをクリアする必要がないこともあって、結果的にそのような問題はありませんでした。しかし、MT5では必要です。私の技術では、カーネルの大きさを変えながら、徐々に充填していく必要があります。配列の中には、正確なサイズが事前にわからないものがあります。セル内にゴミがなければ、とっくにうまくいっているはずだ。

つまり、一方ではアレイのゴミがあり、他方ではオーバーランのクリティカルエラーがあるのです。まるでドラえもんのような条件ですが...。

なぜ、MT4のように、配列の自動クリアを削除し、宣言された変数を ゼロにしなければならなかったのか理解したいのですが?

変数を許容すると、大きな配列では常にゴミが溜まるという問題に直面することになり、宣言時だけでなくリサイズ時にもゴミを片付けなければならなくなる...。なぜ?

 

境界を越える理由は、配列はさまざまな関数で少しずつ値を埋めていくが、その過程で、あるセルが別のセルを経由してアクセスされるからである。一部の関数は2回呼び出され、順次配列を埋めて いきます。しかし、マス目にゴミがあると、1回目の充填でオーバーしてしまいます。

あらかじめ配列をクリアしておけば問題は解決するのでしょうが、当然ながらこれはさらなる頭痛の種となります。可哀想に。

 
よし、文句を言うのはやめよう。))ただ、慣れが必要です))
 

慣れることです。

私はいつも、配列を宣言 し、予想されるサイズを設定し、値を入れて(初期化)います。ゼロ以外の値で初期化したほうが、エラーを発見しやすいことが多いのです。

 
ピーター、意味がわからないんだけど?
動的配列が あり、この配列の現在のサイズがあり、オーバーフロー制御がある。
個人的には、アルゴリズムがエラーなく正しくできていればオーバーフローは起こらないので、オーバーフロー制御はなるべく避け、設計段階でのみ使用するようにしています。なぜ不要なチェックが必要なのか?
オーバーフローが発生している場合は、エラーを探します。割り込みポイント付きのデバッガは、オーバーフローが発生したときにデバッグモードでプログラムが停止し、変数を見ることができるため、役に立つか、割り込みポイントなしです。
そして、ゴミがあるとすれば、それはあなたが片付けていないあなたのゴミです。
 
Реter Konow:

今までMT5を真剣に扱ったことがなかったのに、大きなプロジェクトを一気に移管することになりました。当然ながら難点もあり、そのひとつは配列が常に範囲外になってしまうことです。MT4では、発表後にわざわざアレイをクリアする必要がないこともあって、結果的にそのような問題はありませんでした。しかし、MT5では必要です。私の技術では、カーネルの大きさを変えながら、徐々に充填していく必要があります。配列の中には、正確なサイズが事前にわからないものがあります。セル内にゴミがなければ、とっくにうまくいっているはずだ。

つまり、一方ではアレイのゴミがあり、他方ではオーバーランのクリティカルエラーがあるのです。まるでドラえもんのような条件ですが...。

なぜ、MT4のように、配列の自動クリアを削除し、宣言された変数を ゼロにしなければならなかったのか理解したいのですが?

変数を許容すると、大きな配列では常にゴミが溜まるという問題に直面することになり、宣言時だけでなくリサイズ時にもゴミを片付けなければならなくなる...。なぜ?

また、当初は同じような苦労がありました。

私の意見では、配列は特定の方法で満たされます。これは、しばしばループで考慮されるべきです。

 
Nikolai Semko:
ピーター、意味がわからないんだけど?

一通りhttps://www.mql5.com/ru/forum/293630/page179#comment_10802823

今度はMQL5のせいだ...。;)

Мой подход. Ядро - Движок.
Мой подход. Ядро - Движок.
  • 2019.02.28
  • www.mql5.com
В этой ветке, я хочу рассказать о своем подходе в программировании. Заранее предупреждаю, - здесь не будет обсуждений GUI...
 
Igor Makanu:

一通りhttps://www.mql5.com/ru/forum/293630/page179#comment_10802823

今度はMQL5のせいだ...。;)

なるほど、MQL4には慣れていないんです。
えっ、本当に、そこにオーバーフローを制御する必要はないのですか?でも、ひどいですよね。エラーはどのようにキャッチするのですか?
 
Nikolai Semko:
ああ、MQL4に慣れていないんだ。
えっ、本当に、オーバーフローを制御する必要はないんですか?でも、それはひどいですよね。エラーを検出する方法は?

ニコライさん、MQL4は心配いりませんよ、すべて順調です。トピックスターターは、好きなようにアレイを埋めて いく。それだけです。

 
Nikolai Semko:
まあ、そうですね。 MQL4に慣れていないので。
えっ、本当に、オーバーフローを制御する必要は ないんですか?でも、それはひどいですよね。エラーはどのようにキャッチするのですか?

もちろん、そうでしょう。

自分自身と自分のプログラムを尊重するプログラマーなら、物事を失敗させることはないだろう。MQL4では、#property strictを使用しない場合、インデックス20でサイズ10の配列を参照することができます。そして何も起こらない。プログラムは動き続けるが、次に何を使うかはプログラマーの判断に委ねられる。頭が良ければ、確かに配列の 外に値が出ないように、すべてチェックして制御するのでしょうが、「ぶっつけ本番」でやると、この制御はどうでもよくなり、「動くことが一番大事で、どうやったらどうなるか...」ということになるのでしょう。
従来のように自作をごまかすことができないため、手をこまねいていた大多数のユーザーから「悪い、悪い、複雑なMQL5」と不満の声が上がっています。しかし、元々、受信データをチェックし、制御しながらコードを考えて作っていた人たちは、言語の複雑さの違いに気づかず、「どこが複雑なんだ、同じじゃないか......」と、今になって思っているのです。

 
Реter Konow:

今までMT5を真剣に扱ったことがなかったのに、大きなプロジェクトを一気に移管することになりました。

配列を書き換えたときの深刻な違い

トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム

mql4言語の特徴、微妙なニュアンスとコツ

fxsaber, 2019.02.12 13:12

多次元配列 に対するArrayResizeの機能
void OnStart()
{
  int Array[][2];
  
  Print(ArrayResize(Array, 7)); // MQL5 - 7, MQL4 - 14
  Print(ArraySize(Array));      // 14
}