Статья о традиционных и не совсем традиционных алгоритмах усреднения, упакованных в максимально простые и достаточно однотипные классы. Они задумывались для универсального использования в практических разработках индикаторов. Надеюсь, что предложенные классы в определенных ситуациях могут оказаться достаточно актуальной альтернативой громоздким, в некотором смысле, вызовам пользовательских и технических индикаторов.
Не секрет, что большую часть информации об окружающем мире человек получает при помощи зрения. Справедливо это и в такой области как трейдинг. Новая платформа MetaTrader 5 и язык MQL5 открывают новые возможности для представления визуальной информации трейдеру. В данной статье предлагается универсальная и расширяемая система классов, которая берет на себя всю черновую работу по организации вывода произвольной текстовой информации.
1.
構造体へのポインタの配列（アレイ）を作成し、初期化する for(i){ S[i] = GetPointer(StaticStruct[i]); }.
2.意味のあるデータを強固に（詰めて）配列しておくこと。
OpenCLのrawバッファへのデータ出力（またはDLLへの送信、ファイルへの書き込みなど）を扱う場合に重要。
同時に、データを書き換えることなく、データアクセスの順序を入れ替えることも可能です（ポインターのソート時など）。
安全な実行を行う言語は、直接アクセスを公開したり与えたりすべきではない。
クラスはプロテクションが多いからこそ、ハンドルがあるのです。
セキュリティを重視するため、他のオブジェクトのハンドルはありません。
OpenCL では、データの受け渡しに、構造体を含む任意のデータ型を使用することができます。そこではvoid*が使われている。必要な形式で統一されたデータを 用意するだけで、すぐに作業に取り掛かることができます。そんなことはしたくない、自分のやり方でやりたい」という質問を想定して、「それはできない、セキュリティの方が重要だ」と答えています。
1. OpenCL では、構造体を含め、どのようなデータ型でも データ転送に使用することができます。そこではvoid*が使われている。必要な形式で統一されたデータを 用意するだけで、すぐに作業に取り掛かることができます。そんなやり方は嫌だ、自分のやり方でやりたい」という質問を想定して、「それはできない、セキュリティの方が重要だ」と答える。
2.安全な実行を行う言語は、直接アクセスを公開/許可してはならない。
重要なのは、最も原始的なものを含むすべてのクラスについて、mql5コンパイラはVMTを作成し、オブジェクトに対応する隠しフィールド（VMTへのポインタ）を作成します。 そしてこの生バッファ（ファイル）へのポインタが私には大きすぎるのです。ゴミになるだけでなく、パケットのアライメントを不適切に崩してしまいます（OpenCLのバッファは128ビットアライメント）。 そこがポイントです。 クラスは使いたくなります。mqlで扱うには便利です。 しかし...をご覧ください。
Delphiでは、VMTの実装に代わる良い例があります。 VMTへのポインタは、クラス階層に最初の仮想メソッドが現れてから、クラスに現れます。 mql5でも同じなら、状況はもっと管理しやすくなるでしょう。 構造体の代わりに仮想メソッドのないクラスを使用でき、構造を破壊する「アドオン」は存在しないでしょう。
現在、構造体の配列をカプセル化した抽象 （継承を目的とした）クラスの実装が、継承されたサービス（ソートなど）に適していない状況に遭遇しています。構造体の配列をクラスの配列に置き換えることで、この問題は解決されますが、別の問題が発生します......。(前出）。
また、「直接アクセス」は一切求めていませんし、アドレス演算にも興味はありません。なぜ、無駄に子どもたちを怖がらせるのですか？:) mql5のハンドルは「生の」ポインタに近いものではありません。そして、もし（密かに）そうであれば、本当のセキュリティホールはここにあり、あらゆるユーザーデータへのハンドル（疑似ポインタ）の実装にあるわけではないのです。
---
今の構造体は、実際には仮想関数（とVMT）を持たないクラスです。 ですから、それらにクラスの機能（ハンドル）を追加すればいいのです。そうすれば、配列へのポインタもそれほど必要なくなります（必要なら構造体にラップすればいい）。
重要なのは、私が自分のやり方でやりたいのではなく、最も原始的なものを含むすべてのクラスについて、mql5コンパイラはVMTとそれに対応するオブジェクトの隠しフィールド（VMTへのポインタ）を作成します。 そしてこの生バッファ（ファイル）へのポインタが私には多すぎるということなのです。ゴミになるだけでなく、パケットのアライメントを完全に崩してしまいます（OpenCLのバッファは128ビットアライメント）。 そこがポイントです。 クラスを使うのは魅力的です。mqlで扱うには便利です。 しかし...をご覧ください。
Delphiでは、VMTの実装に代わる良い例があります。 VMTへのポインタは、クラス階層に最初の仮想メソッドが現れてから、クラスに現れます。 mql5でも同じなら、状況はもっと管理しやすくなるでしょう。 構造体の代わりに仮想メソッドのないクラスを使うことができ、構造を破壊する「アドオン」は存在しないのです。
現在、構造体の配列をカプセル化した抽象 （継承を目的とした）クラスの実装が、継承されたサービス（ソートなど）に適していない状況に遭遇しています。構造体の配列をクラスの配列に置き換えることで、この問題は解決されますが、別の問題が発生します......。(前出）。
また、「直接アクセス」は一切求めていませんし、アドレス演算にも興味はありません。なぜ、無駄に子どもたちを怖がらせるのですか？:) mql5のハンドルは「生の」ポインタに近いものではありません。そして、もし（密かに）そうだとしたら--だから、本当のセキュリティホールはここにあるのだが、あらゆるユーザーデータへのハンドル（疑似ポインタ）の実装にはないのである。
抽象的なデータ（これはすでに多くの内部メタデータとリレーションシップを意味します）で複雑なシステムを構築し、それをトリッキーな方法で変更できる制御されていないOpenCL環境に渡したい。 そのため、仮想テーブルを上書きする機能がなく、シンプルなオブジェクトと配列だけが自由に操作できるようにしています。
実は、あなたは「抽象的な構成の自由」を通じて間接的に直接アクセスを要求しているのです。これは、セキュリティのためによく検討し、アーキテクチャ的にカバーしてきたテーマです。MQL5のクラスは、セキュリティに重点を置いた独自のルールで動いています。それ以外のタイプにはハンドルがありません。単純な型や構造体のハンドルの代わりに、配列のインデックスを使用することができます。
MQL5のハンドル自体は正しい（1つから増える）ので、確認してみてください。
1. 抽象的なデータ（これはすでに多くの内部メタデータと関係を意味します）で複雑なシステムを構築し、それを巧妙に変更できる制御されていない OpenCL 環境に渡したい。これが、仮想テーブルを上書きする機能なしに、単純なオブジェクトと配列だけを自由に動作させる理由です。
2.あなたは、実は間接的に「抽象的な構成の自由」を通じて直接アクセスを要求しているのです。このトピックは、私たちがよく研究し、セキュリティのためにアーキテクチャ的にカバーしています。MQL5のクラスは、セキュリティを重視し、独自のルールで動いています。
MQL5のハンドルは正しい（1つから増える）ので、ご自身で確認してみてください。
メタデータ（ハンドル）を持たず、厳密にクリーンなデータをバッファに渡したい。このメタデータはバッファに入れる必要はありません。 バッファに入れると邪魔になりますし、CLBufferWrite() がそれを許さないので、バッファに入れることもできません。そして、これは正しいのです。
2.実際に ダイレクトアクセスを要求しているわけではなく、（必要であれば）DLLを使ってダイレクトアクセスすることができます。
aPointer = memcpy(a,a);
を使えば、生ポインタの取得の問題は解決します。レナート本当の 問題に迫ってみてください。実際に存在しない」ものを作ってはいけない。実際に存在するものすべて--私はそれを、依頼の微妙なニュアンスもなく、ダイレクトに表現したのです。安全性の問題を十分に理解した上で、できる限り建設的に。
3.それは素晴らしいことです。
--
構造体の動的な作成と削除（new, delete）は一切行わない方が良い。そうすれば、セキュリティの問題も発生しません。 実は」（あなたの言葉で言えば）何が問題なのかは理解しています。 動的オブジェクトの実タイプの定義の問題があります。 クラスの場合は、VMTへのポインタを解析することで解決することが多いようです。ただし、動的な構造がない場合は、問題ありません。
考えてみてください。どんな規模の存在に対しても、「ハンドル」とは何でしょうか。
合理的な数のオブジェクト（クラス、ファイルなど）に対してハンドルを提供することができます。しかし、任意のサイズの配列領域に入った場合、どのハンドルもメモリの一部を直接参照 できる可能性があるだけ です。そうしないと、「ハンドル→メモリ」のマッピングテーブルが、参照される実体よりもさらに多くのメモリを食いつぶしてしまうからです。
また、セキュリティ規定に基づき、メモリへの直接のポインタであるハンドルは持てません。だから、「あらゆる無限の存在」に対するハンドルは存在しないのです。
Renat:
1. 妥当な数のオブジェクト（クラス、ファイルなど）に対するハンドルを用意できる。しかし、任意のサイズの配列領域に入った場合、どのハンドルもメモリの一部を直接参照 できる可能性があるだけ です。そうしないと、ハンドル→メモリのマッピングテーブルが、参照される実体よりもさらに多くのメモリを消費してしまいます。
2.また、セキュリティ条項に基づき、メモリへの直接ポインタであるハンドルは持てない。だから、「あらゆる無限の存在」に対するハンドルは存在しないのです。
1.建設的なのはいいことだ。考えていたんです。この問題は、まさに巨大な構造体について提起されたものです。 小さな構造体では、コピー時間はとにかく短いです。 ここで問題が生じるのは、ユーザーの理不尽さだけだと思いますが、とにかく「愚かにも」メモリをいっぱいにすることができます（たとえば、インジケータバッファなど）。 特に必要もないのに 静的構造体の ハンドルで作業したい人はいないと思います。 メモリをオーバーフローしたら自分のせいですしね。民間の戯言はそんなに気にしなくていい、どうせすべてを防ぐ（予測する）ことはできないのだから。:)
2.いやいや、直接ポインターは必要ないですが、「制限のない実体」でもハンドルはあったほうが困りません。要は、使う義務がないということです。 そうすれば、みんなの分のメモリは十分に確保できます。:)
ここで吠える意味がわからない。ハンドルが欲しいなら、構造体をクラスとして 宣言する、ただそれだけです。
メモリに直接アクセスしたい場合は、DLLを書きます。
ここで首を折る意味がわからない。
1. ハンドルが欲しいなら、構造体をクラスとして 宣言する、ただそれだけです。
2.メモリに直接アクセスさせたい場合は、DLLを書く。
1.そこが問題なのです。バッファにクラスの配列を書き込む必要はない(無理だし)。そこに構造を書かないといけない。そして、それを素早く（実際にクラスから構造体に書き換えることなく）実現したいのです。また、並べ替えアクセスにはハンドルが必要です（さらに、異なるキーでソートする場合）。
代用品は私自身のインデックステーブルかもしれません。しかしそうなると、一度規定されたサービス（ソートやバイナリ検索）と共に、 それを継承する機能を持つ 構造体の配列で作業をカプセル化するクラスを作ることができません。
2.いらないよ！!!！！！その場で言い訳するのはやめてください。:))
いいえ、そのようなヘンドルをすることはありません。これは完全な悪であり、私たちは最後までその責任を問われることになります。
理想的な解決策は、パラメータ化可能なクラスです。
class MyClass<T> { T MyArray[]; .... };でも、もうその話もしないし、した方がいいのかも？