MT5で配列の強制クリア？ - ページ 2

新しいコメント
 
Artyom Trishkin:

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

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

このコードでは、#property strictを使用しないゼロによる除算は許可されており、惑星がブラックホールに崩壊することはありませんが、ゼロで除算したい場合もありますが、それは許可されていません。
 
Алексей Тарабанов:

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

アルチョム・トリシキン

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

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

ガッカリ!
さて、ペトル、MQL5の厳密さのおかげで、コードを相対的な順序に並べ、ゴミの山を片付けるチャンスがあるんだ。
また、#property strictで修正したコードをMQL4に戻してコンパイルしてみると、MT4でより速く動作するようになるかもしれません。

 
Nikolai Semko:

ガッカリ!
さて、ピーターさん、MQL5の厳密さのおかげで、コードを相対的に整理して、ゴミの山を片付ける 機会ができました。
修正したコードをMQL4で#property strictでコンパイルし直せば、MT4で高速に動作するかもしれません。

そうやって、私のコードがゴミだらけだと先験的に判断したんですね。

説明しますと、カーネルは何段階かに分けて充填されます。MT5で配列を宣言するときにゴミが入っていると（私は知りませんでしたが）、関数でカーネルを構築する最初のステップで、配列の外側にオーバーフローが発生します。ゼロが含まれていれば問題なく、2回目の実行で正しい値を得ることができますが、ゴミが含まれていると重大なエラーが 発生します。

その点はご理解いただけましたか？

 
Nikolai Semko:
ピーター 意味不明です。
...

そのとおり、あなたはわかっていない。私の仕事と自分の仕事を比べているのか...。

 
...
オーバーフローが起きている場合は、自分自身にエラーがないか探してみてください。
そして、もしゴミがあるとすれば、それはあなたが片付けていないあなたのゴミです。

オーバーフローはしていません。私の技術の具体的な内容を考えてみてください（無視しているのを忘れています）。配列の別のセルをあるセルへのポインタとして使用し、その中にゴミがあった場合、配列から外れてしまうのです。問題は、参照するセルが正しい値を得るためには、カーネル構築の第2ラウンドに進まなければならないことです。そして2周目には、正しい値が表示される。でも、致命的なミス で2回戦に進めないんですよね。

これはすべて、宣言された配列の中にゴミがあることが原因です。

そこで、1回目のサイズ設定（通常領域の構築）の段階と、2回目のサイズ変更（ユーザー領域の構築）の段階で、2次元配列（カーネル）をクリアする仕組みを考案する必要がある。

 
Реter Konow:

そのとおり、あなたはわかっていない。比較されるのは、私のタスクとあなた自身の...

一人芝居をどうぞ-あと10回連続で投稿してください。

 
Реter Konow:

こうして、先験的に私のコードがゴミだらけだと判断されたわけです。

説明しますと、カーネルは何段階かに分けて充填されます。もしMT5で配列を宣言するときにゴミが入っていたら（私は知らなかった）、関数でカーネルを構築する最初のステップで、配列はスコープの外にあります。ゼロが含まれていれば問題なく、2回目の実行で正しい値を得ることができますが、ゴミが含まれていると重大なエラーが 発生します。

その点はご理解いただけましたか？

全然 そんなことないんですけどね。ゴミのせいではなく、mql4には#property strictがないのが原因です。これがないと、配列オーバーランの代わりに0が返され、mql5ではすでにクリティカルエラーになっています。おそらく、存在しない配列インデックスの内容をチェックするのではなく、配列の長さをチェックする方がよいでしょう。

 
Alexey Viktorov:

Retagは 全くそんなことはありません。悪いのはゴミではなく、mql4で#property strictがないことです。このギミックがないと、配列オーバーランの代わりに0が表示され、mql5ではすでにクリティカルエラーになっています。おそらく、存在しない配列インデックスの内容をチェックするのではなく、配列の長さをチェックする方がよいでしょう。

アウトオブバウンズは、指示する セル内にゴミがあるために発生します。

例えば、こんな感じです。

G_CORE[Объект][Канвас] = G_CORE[Окно][Его_канвас];

イニシャルです。

G_CORE[Object][Kanvas] = -123423452345; (ゴミ)

G_CORE[Window][His_canvas]= -452345; (ゴミ)

//-----------------------------------------------------------------

結果が配列から外れている。

再掲します。MT4では値がゼロのセルもあり、第1段階のコアフィリングでは第2ラウンドで埋められます。

MT5では、セルがゴミのため、1巡目でクリティカルエラーに なる。

もし、配列のセルがゼロであれば、エラーは発生せず、カーネルは順次充填される（はずである）。

 

ここでは、より正確な例をご紹介します。

カーネル構築の第一弾。ある機能では

int Ширина_канваса = G_CORE[G_CORE[Окно][Его_канвас]][_X_SIZE];

Если G_CORE[Окно][Его_канвас] = 234523452345; (мусор) то ошибка. А если бы G_CORE[Окно][Его_канвас] = 0; Ошибки нет, и ядро продолжает нормально строится.
 
Реter Konow:

アウトオブバウンズは、指示する セル内にゴミがあるために発生します。

例えば、こんな感じです。

イニシャルです。

G_CORE[Object][Kanvas] = -123423452345; (ゴミ)

G_CORE[Window][His_canvas]= -452345; (ゴミ)

//-----------------------------------------------------------------

結果が配列から外れている。

再掲します。MT4では値がゼロのセルもあり、第1段階のコアフィリングでは第2ラウンドで埋められます。

MT5では、セルがゴミのため、1巡目でクリティカルエラーに なる。

もし配列のセルにゼロがあれば、エラーは発生せず、カーネルは（本来なら）順次埋まっていくはずです。

配列の非初期化は、完全にkodopistaelのせいです。自分の環境の中でエラーを探す。アルゴリズムを再構築する。

1234567
新しいコメント