"ダミー "からの質問 - ページ 125

[Renat Fatkhullin]

MetaDriver:

ああ、今わかったよ。

Renat、私は長い間提案をしてきましたが、まさにその通りです。 少なくとも静的配列には名前付き型付けをしてください（他のすべての型にはすでにあります）。

例えば、typedef Int8 = int[8]; と宣言することが可能です。

構造物を通して簡単に行うことができます。こじつけは一切しません。

struct Int8 { int arr[8]; };

[Vladimir Gomonov]

Renat:

これは、構造物によって簡単に実現できる。複雑に考えすぎないようにしよう。

いいぞ、簡単だ、それでいいんだ！ でも、何が必要なんだ？簡単な ことですか？

あなたのカミソリ「 オカム」と、私たち（ユーザー）のカミソリ「 オカム」は、まったく別のカミソリだと思いませんか？あなたの ミニマリズムは、ユーザーに 余剰を生み出しがちなので、そろそろオカムを近くのフェンスに吊るしておく必要がありそうですね。

そんなにシンプルさが大事なら、通常のサブアレイを関数に渡せるようにしてください！ みんながハッピーになるし、ミニマリストもハッピーになりますよ。

// ちなみに、F4でも問題なく動作します - ダイナミックなものでも。:)

[Yedelkin]

Renat:
もちろん、静止画です。

さて、これでよしとしましょう。チェックするのが遅すぎました :/。

[Renat Fatkhullin]

MetaDriver:

すごいな、簡単だ、それでいいんだ！ でも、何が必要なんだ？水平に ？

私が提案する構造は、新しいエンティティを作成するための標準的な方法です。

何も興奮する必要はない。

[Renat Fatkhullin]

MetaDriver:

現在、mql5では、関数にサブアレイを 渡すことができないため、多くの余分なステップと曲がったコードを書かなければなりません。

制御不能なメモリチャンクへのポインタの話ですが、これはMQL5では完全に禁止されています。

MQL5では、すべてのオブジェクト/タイプが制御可能でなければなりません。これは、言語の安全性を確保するための直接的な要件です。

配列の一部を渡す必要がある場合は、配列自身とその位置への参照を渡す必要があります。これにより、アレイ自体を完全に制御することができます。

[Vladimir Gomonov]

Renat:

制御不能なメモリチャンクへのポインタの話ですが、これはMQL5では完全に禁止されています。

MQL5では、すべてのオブジェクト/タイプが制御可能でなければなりません。これは、言語の安全性を確保するための直接的な要件です。

2.配列の一部を渡す場合は、配列自体への参照と配列内の位置を渡して使用します。これは、アレイ自体を完全に制御するために有効です。

しかも、ネーミングが実装されていないのはここだけなので、言語実体の普遍化というイデオロギーにうまく合致している。

2.すべて同じです。第一に、曲がっていること、第二に、まったく普遍的でないことです。(1)不必要な書き換えや構造体へのラップなしで、2次元のmql-arrayをOpenCLバッファにコピーする方法、または(2)一様でない配列に対してあなた自身の関数ArrayCopy(...)を（速度のために）使用する方法を提案してください。

// 前回は突然の投稿で申し訳ありませんでした。本当に不要。ややこしいことはやめよう」で盛り上がりました。ただ複雑になるだけなので。

2a. ArrayCopy()のような関数に対するあなたの「一次元性の制約」は、コメント中の1つの基本的な節で、多くの場合、苦痛なく和らげることができると思います。"この関数は、多次元配列 がまるごとコピー される限り、多次元配列でも 動作します。"

多くの問題が解消されるでしょう。// もちろん、すべてではありません。

[Renat Fatkhullin]

MetaDriver:

1.私が提案したのは、ネーミングの導入とそれによる厳密な型付けであり、特にここだけはネーミングでカバーされていないので、言語実体の普遍化というイデオロギーによく合致する。

描写の偶然性に気づきたくなかったのでしょう。

typedef Int8 = int[8];
struct   Int8 { int arr[8]; };

2つ目の方法は、よりクリーンでパワフル、そしてコントロールしやすい方法です。既存の方式で、さらに弱いものを発明する理由はまったくない。

2.同じことをすること。すべて同じです。第一に、曲がっていること、第二に、まったく普遍的でないことです。(1) 二次元の mql-array を、不必要な書き換えや構造体へのラップなしに OpenCL バッファにコピーする方法、または(2) 無次元配列のためにあなた自身の関数 ArrayCopy(...) を（速度のために）使用する方法を提案してください。

まず、曲がっていないこと。第二に、制御されないメモリへの直接アクセスというスタイルで、どの最適化手法よりも高い安全性を実現しています。つまり、「バイナリブロックを制御された実体に直接流し込むにはどうしたらいいか」という問題は、すべての言語にとって一般的かつ基本的な（解決可能性の低い）問題なのである。

異なるシステム間で配列転送を行う場合（OpenCLの場合）、シンプルで直接的に互換性のあるデータ 構造を考えることが重要です。

データ転送を簡単にするための最もシンプルなCLBufferWriteのマルチタイプ関数バインドクラスを見てください。

[Vladimir Gomonov]

Renat:

MQL5では完全に禁止されている、制御されていないメモリの一部へのポインタの話をしているのですね。

ついでに言うと、凝縮していますね。コンパイラは、パラメータが 渡される時点で、渡される配列のサイズを知っています。

しようとするとエラーになるくらいです。:)もうひとつは、関数呼び出しのたびに暗黙のパラメータ化を追加で導入しなければならないことです（おおよそ、あなたが明示的に行うようアドバイスしているように）。しかし、あなた側の解決策はもっと普遍的なものでしょう。例えば、関数やオブジェクトの独自の標準ライブラリを使用することです。同じArrayCopy()やFileWriteArray()であれば問題なく動作します。

[Renat Fatkhullin]

papaklass:
私のような人間のために、簡単な例を添えて発言することができるのです。MetaDriverは理解してくれるが、私のような人間は例もなく何を言っているのか理解できない？そして、何が起こっているのかを意識したいものです。

ドキュメント代わりになりそうで怖いです。検索で調べてみてください。情報は山ほどあります。

一部のアレイメンバに安全にアクセスできる。

void MyFunc(double& array[],uint pos,uint size)
  {
   while(size>0)
     {
      Print("[",pos,"] = ",array[pos]);
      pos++;
      size--;
     }
  }

コンパイラがインライン関数に対して非常にシャープになっていることを考慮すると、実際、関数は呼び出し場所に完全に組み込まれ、すべてのオーバーヘッドがゼロになる可能性がある。

つまり、MQL5では、小さな「正しい」関数を書くことを恐れず、適切な最適化を施した標準的なフルインラインの運命を持つことができるのです。

つまり、パラメータ転送や インデックス作成にかかるコストを削減することができるのです。

[Renat Fatkhullin]

MetaDriver:

ついでに言うと、凝縮していますね。コンパイラはパラメータを 渡す時点で渡される配列のサイズを知っています。

いつから全ての配列が静止画になり、インデックスやサイズも全て静止画になったのでしょうか？

配列はほぼ常に動的であり、インデックスは変数であるため、呼び出しの瞬間に本格的な静的チェックを 行うことはできない。メタ/ルチチェックを するだけなので、メモリの一部を適当に作業するのではなく、オブジェクト/ディスクリプション全体にアクセスできることがとても重要です。

同じArrayCopy()やFileWriteArray()であれば問題なく動作します。

心配しないでください、すべてはずっと前から考えられていたことなんです。

私たちがよく知っているセキュリティの原則を破った結果は、「4月にさらに12の重大なバグを修正して、仮想マシンから抜け出してシステムを制御する」という方法です。