MT5で配列の強制クリア? - ページ 2 1234567 新しいコメント Aleksey Semenov 2019.03.03 21:40 #11 Artyom Trishkin:もちろん、そうでしょう。 自分自身と自分のプログラムを尊重するプログラマーは、物事を成り行きに任せたりはしないものです。MQL4では、#property strictを使用しない場合、インデックス20でサイズ10の配列を参照することができます。そして何も起こらない。プログラムは動き続けるが、次に何を使うかはプログラマーの判断に委ねられる。頭のいい人なら、確かに配列の 外に値が出ないように、すべてチェックして制御するのでしょうが、「大雑把に」やっていると、そんな制御は考えず、「動くことが一番大事だけど、どう動くかは、なんとなく...」ということになります。 従来のように自作をごまかすことができないため、手をこまねいている大多数のユーザーから「悪い、悪い、複雑なMQL5」と不満の声が上がっています。しかし、元々、受信データのチェックや制御を考えてコードを作っていた人たちは、言語の複雑さの違いに気づかず、「どこが複雑なんだ、同じじゃないか......」と、今になって思っているのです。 このコードでは、#property strictを使用しないゼロによる除算は許可されており、惑星がブラックホールに崩壊することはありませんが、ゼロで除算したい場合もありますが、それは許可されていません。 Nikolai Semko 2019.03.03 22:26 #12 Алексей Тарабанов:ニコライさん、MQL4については心配いりません。トピックスターは、アレイを好きなように埋めて いく。すべてです。 アルチョム・トリシキンもちろん、そうでしょう。 自分自身と自分のプログラムを尊重するプログラマーなら、物事を見過ごすことはない。MQL4では、#property strictを使用しない場合、インデックス20でサイズ10の配列を参照することができます。そして何も起こらない。プログラムは動き続けるが、次に何を使うかはプログラマーの判断に委ねられる。頭のいい人なら、確かに配列の 外に値が出ないように、すべてチェックして制御するのでしょうが、「大雑把に」やっていると、そういう制御は考えず、「動くことが一番大事だけど、どう動くかは、なんとなく...」ということになるのでしょう。 従来のように自作をごまかすことができないため、手をこまねいていた大多数のユーザーから「悪い、悪い、複雑なMQL5」と不満の声が上がっています。しかし、元々、受信データのチェックや制御を考えてコードを作っていた人たちは、言語の複雑さの違いに気づかず、「どこが複雑なんだ、同じじゃないか......」と、今になって思っているのです。 ガッカリ! さて、ペトル、MQL5の厳密さのおかげで、コードを相対的な順序に並べ、ゴミの山を片付けるチャンスがあるんだ。 また、#property strictで修正したコードをMQL4に戻してコンパイルしてみると、MT4でより速く動作するようになるかもしれません。 Реter Konow 2019.03.04 09:17 #13 Nikolai Semko: ガッカリ! さて、ピーターさん、MQL5の厳密さのおかげで、コードを相対的に整理して、ゴミの山を片付ける 機会ができました。 修正したコードをMQL4で#property strictでコンパイルし直せば、MT4で高速に動作するかもしれません。そうやって、私のコードがゴミだらけだと先験的に判断したんですね。 説明しますと、カーネルは何段階かに分けて充填されます。MT5で配列を宣言するときにゴミが入っていると(私は知りませんでしたが)、関数でカーネルを構築する最初のステップで、配列の外側にオーバーフローが発生します。ゼロが含まれていれば問題なく、2回目の実行で正しい値を得ることができますが、ゴミが含まれていると重大なエラーが 発生します。 その点はご理解いただけましたか? Реter Konow 2019.03.04 09:22 #14 Nikolai Semko: ピーター 意味不明です。...そのとおり、あなたはわかっていない。私の仕事と自分の仕事を比べているのか...。 Реter Konow 2019.03.04 09:28 #15 ...オーバーフローが起きている場合は、自分自身にエラーがないか探してみてください。そして、もしゴミがあるとすれば、それはあなたが片付けていないあなたのゴミです。オーバーフローはしていません。私の技術の具体的な内容を考えてみてください(無視しているのを忘れています)。配列の別のセルをあるセルへのポインタとして使用し、その中にゴミがあった場合、配列から外れてしまうのです。問題は、参照するセルが正しい値を得るためには、カーネル構築の第2ラウンドに進まなければならないことです。そして2周目には、正しい値が表示される。でも、致命的なミス で2回戦に進めないんですよね。 これはすべて、宣言された配列の中にゴミがあることが原因です。 そこで、1回目のサイズ設定(通常領域の構築)の段階と、2回目のサイズ変更(ユーザー領域の構築)の段階で、2次元配列(カーネル)をクリアする仕組みを考案する必要がある。 Vitaly Muzichenko 2019.03.04 09:29 #16 Реter Konow:そのとおり、あなたはわかっていない。比較されるのは、私のタスクとあなた自身の...一人芝居をどうぞ-あと10回連続で投稿してください。 Alexey Viktorov 2019.03.04 09:57 #17 Реter Konow:こうして、先験的に私のコードがゴミだらけだと判断されたわけです。 説明しますと、カーネルは何段階かに分けて充填されます。もしMT5で配列を宣言するときにゴミが入っていたら(私は知らなかった)、関数でカーネルを構築する最初のステップで、配列はスコープの外にあります。ゼロが含まれていれば問題なく、2回目の実行で正しい値を得ることができますが、ゴミが含まれていると重大なエラーが 発生します。 その点はご理解いただけましたか?全然 そんなことないんですけどね。ゴミのせいではなく、mql4には#property strictがないのが原因です。これがないと、配列オーバーランの代わりに0が返され、mql5ではすでにクリティカルエラーになっています。おそらく、存在しない配列インデックスの内容をチェックするのではなく、配列の長さをチェックする方がよいでしょう。 Реter Konow 2019.03.04 10:47 #18 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巡目でクリティカルエラーに なる。 もし、配列のセルがゼロであれば、エラーは発生せず、カーネルは順次充填される(はずである)。 Реter Konow 2019.03.04 10:51 #19 ここでは、より正確な例をご紹介します。カーネル構築の第一弾。ある機能では int Ширина_канваса = G_CORE[G_CORE[Окно][Его_канвас]][_X_SIZE]; Если G_CORE[Окно][Его_канвас] = 234523452345; (мусор) то ошибка. А если бы G_CORE[Окно][Его_канвас] = 0; Ошибки нет, и ядро продолжает нормально строится. Vladimir Karputov 2019.03.04 10:54 #20 Реter Konow:アウトオブバウンズは、指示する セル内にゴミがあるために発生します。 例えば、こんな感じです。 イニシャルです。 G_CORE[Object][Kanvas] = -123423452345; (ゴミ) G_CORE[Window][His_canvas]= -452345; (ゴミ) //----------------------------------------------------------------- 結果が配列から外れている。 再掲します。MT4では値がゼロのセルもあり、第1段階のコアフィリングでは第2ラウンドで埋められます。 MT5では、セルがゴミのため、1巡目でクリティカルエラーに なる。 もし配列のセルにゼロがあれば、エラーは発生せず、カーネルは(本来なら)順次埋まっていくはずです。配列の非初期化は、完全にkodopistaelのせいです。自分の環境の中でエラーを探す。アルゴリズムを再構築する。 1234567 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
もちろん、そうでしょう。
自分自身と自分のプログラムを尊重するプログラマーは、物事を成り行きに任せたりはしないものです。MQL4では、#property strictを使用しない場合、インデックス20でサイズ10の配列を参照することができます。そして何も起こらない。プログラムは動き続けるが、次に何を使うかはプログラマーの判断に委ねられる。頭のいい人なら、確かに配列の 外に値が出ないように、すべてチェックして制御するのでしょうが、「大雑把に」やっていると、そんな制御は考えず、「動くことが一番大事だけど、どう動くかは、なんとなく...」ということになります。
従来のように自作をごまかすことができないため、手をこまねいている大多数のユーザーから「悪い、悪い、複雑なMQL5」と不満の声が上がっています。しかし、元々、受信データのチェックや制御を考えてコードを作っていた人たちは、言語の複雑さの違いに気づかず、「どこが複雑なんだ、同じじゃないか......」と、今になって思っているのです。
ニコライさん、MQL4については心配いりません。トピックスターは、アレイを好きなように埋めて いく。すべてです。
もちろん、そうでしょう。
自分自身と自分のプログラムを尊重するプログラマーなら、物事を見過ごすことはない。MQL4では、#property strictを使用しない場合、インデックス20でサイズ10の配列を参照することができます。そして何も起こらない。プログラムは動き続けるが、次に何を使うかはプログラマーの判断に委ねられる。頭のいい人なら、確かに配列の 外に値が出ないように、すべてチェックして制御するのでしょうが、「大雑把に」やっていると、そういう制御は考えず、「動くことが一番大事だけど、どう動くかは、なんとなく...」ということになるのでしょう。
従来のように自作をごまかすことができないため、手をこまねいていた大多数のユーザーから「悪い、悪い、複雑なMQL5」と不満の声が上がっています。しかし、元々、受信データのチェックや制御を考えてコードを作っていた人たちは、言語の複雑さの違いに気づかず、「どこが複雑なんだ、同じじゃないか......」と、今になって思っているのです。
ガッカリ!
さて、ペトル、MQL5の厳密さのおかげで、コードを相対的な順序に並べ、ゴミの山を片付けるチャンスがあるんだ。
また、#property strictで修正したコードをMQL4に戻してコンパイルしてみると、MT4でより速く動作するようになるかもしれません。
ガッカリ!
さて、ピーターさん、MQL5の厳密さのおかげで、コードを相対的に整理して、ゴミの山を片付ける 機会ができました。
修正したコードをMQL4で#property strictでコンパイルし直せば、MT4で高速に動作するかもしれません。
そうやって、私のコードがゴミだらけだと先験的に判断したんですね。
説明しますと、カーネルは何段階かに分けて充填されます。MT5で配列を宣言するときにゴミが入っていると(私は知りませんでしたが)、関数でカーネルを構築する最初のステップで、配列の外側にオーバーフローが発生します。ゼロが含まれていれば問題なく、2回目の実行で正しい値を得ることができますが、ゴミが含まれていると重大なエラーが 発生します。
その点はご理解いただけましたか?
ピーター 意味不明です。
そのとおり、あなたはわかっていない。私の仕事と自分の仕事を比べているのか...。
オーバーフローはしていません。私の技術の具体的な内容を考えてみてください(無視しているのを忘れています)。配列の別のセルをあるセルへのポインタとして使用し、その中にゴミがあった場合、配列から外れてしまうのです。問題は、参照するセルが正しい値を得るためには、カーネル構築の第2ラウンドに進まなければならないことです。そして2周目には、正しい値が表示される。でも、致命的なミス で2回戦に進めないんですよね。
これはすべて、宣言された配列の中にゴミがあることが原因です。
そこで、1回目のサイズ設定(通常領域の構築)の段階と、2回目のサイズ変更(ユーザー領域の構築)の段階で、2次元配列(カーネル)をクリアする仕組みを考案する必要がある。
そのとおり、あなたはわかっていない。比較されるのは、私のタスクとあなた自身の...
一人芝居をどうぞ-あと10回連続で投稿してください。
こうして、先験的に私のコードがゴミだらけだと判断されたわけです。
説明しますと、カーネルは何段階かに分けて充填されます。もしMT5で配列を宣言するときにゴミが入っていたら(私は知らなかった)、関数でカーネルを構築する最初のステップで、配列はスコープの外にあります。ゼロが含まれていれば問題なく、2回目の実行で正しい値を得ることができますが、ゴミが含まれていると重大なエラーが 発生します。
その点はご理解いただけましたか?
全然 そんなことないんですけどね。ゴミのせいではなく、mql4には#property strictがないのが原因です。これがないと、配列オーバーランの代わりに0が返され、mql5ではすでにクリティカルエラーになっています。おそらく、存在しない配列インデックスの内容をチェックするのではなく、配列の長さをチェックする方がよいでしょう。
Retagは 全くそんなことはありません。悪いのはゴミではなく、mql4で#property strictがないことです。このギミックがないと、配列オーバーランの代わりに0が表示され、mql5ではすでにクリティカルエラーになっています。おそらく、存在しない配列インデックスの内容をチェックするのではなく、配列の長さをチェックする方がよいでしょう。
アウトオブバウンズは、指示する セル内にゴミがあるために発生します。
例えば、こんな感じです。
イニシャルです。
G_CORE[Object][Kanvas] = -123423452345; (ゴミ)
G_CORE[Window][His_canvas]= -452345; (ゴミ)
//-----------------------------------------------------------------
結果が配列から外れている。
再掲します。MT4では値がゼロのセルもあり、第1段階のコアフィリングでは第2ラウンドで埋められます。
MT5では、セルがゴミのため、1巡目でクリティカルエラーに なる。
もし、配列のセルがゼロであれば、エラーは発生せず、カーネルは順次充填される(はずである)。
ここでは、より正確な例をご紹介します。
カーネル構築の第一弾。ある機能では
アウトオブバウンズは、指示する セル内にゴミがあるために発生します。
例えば、こんな感じです。
イニシャルです。
G_CORE[Object][Kanvas] = -123423452345; (ゴミ)
G_CORE[Window][His_canvas]= -452345; (ゴミ)
//-----------------------------------------------------------------
結果が配列から外れている。
再掲します。MT4では値がゼロのセルもあり、第1段階のコアフィリングでは第2ラウンドで埋められます。
MT5では、セルがゴミのため、1巡目でクリティカルエラーに なる。
もし配列のセルにゼロがあれば、エラーは発生せず、カーネルは(本来なら)順次埋まっていくはずです。
配列の非初期化は、完全にkodopistaelのせいです。自分の環境の中でエラーを探す。アルゴリズムを再構築する。