私のアプローチコアはエンジンです。 - ページ 4

新しいコメント
 
OOPはカーネルの実装を邪魔しない、それどころか
通常、コードとデータがあります。カーネルとは、この場合、データから強く分離されたコードのことです。また、データはコードそのものであることもあります。カーネルは通常、特定のデータを処理するためのより完全な機能、あるいは少なくともいくつかの自己充足的な最小限の機能を備えています。
この方法では、最も便利なデータ形式を使用することができます、それは多くのデータがあることが想定されます。
エキスパートアドバイザーにはたくさんのストラテジーがありますが、データはストラテジーのロジックのみを表し、それらを管理する機能、つまり注文管理、リスク管理、取引環境との連携、指標、エラー処理、一部またはすべての統計の表示、トレール/グリッド/...機能などがコアとなります。
 

Реter Konow:

配列を作成し、そこに作成したいボタンのプロパティの値を書き込むのです。

ボタンは、Base、Text、Pictureの 3つのオブジェクトから構成されています。

各オブジェクトはボタン要素の中に存在するため、配列は2次元でなければなりません。

では、なぜわざわざ配列にするかというと、構造体を使えばいいのです。そして、これらの値をインデックスではなく、フィールド名で人間的に扱うことができます（これは、多くの愚かな間違いを引き起こす可能性があります）。

その結果、2次元の配列ではなく、構造体の配列になります。 宣言は同じ簡潔さですが、シンプルさと信頼性ははるかに高く、さらに各フィールドが独自の型を持っているので、合理的にメモリを使用できます。 そして、OOPは全く関係ありません。

以下はその一例です。

struct TObject { char type;  string name;  int x;  int y;  int width;  int height;  color clr; };

TObject Objects[]= { { OBJ_BITMAP, "Bitmap", 100, 100, 200, 200, clrRed },
                     { OBJ_BUTTON, "Button", 150, 150, 50, 10, clrWhite },
                   };
 
Alexey Navoykov:


宣言は同じですが、各フィールドが独自の型を持つため、利便性と信頼性が格段に向上し、メモリの使用も合理的になります。 そして、OOPは全く関係ありません。


構造体の配列と構造体の配列、どっちがいいんだろう......？

が、MQLはForthranの配列で動くように設計されているのは事実です...。

 
Maxim Kuznetsov:

構造体の配列と構造体の配列、どちらが良いのでしょうか？

どのような配列構造なのでしょうか？ 筆者は、ただ配列

 

Visual C++でDialogBoxのテンプレートを作成し、そこにButton, CheckBox, EditBox, ComboBoxなどのコントロールをドラッグ＆ドロップする方法をPeterは見たことがないようです。

つまり、Windowsで見ることのできる要素で、フィールドや文字列の調整でDB文字列を表示するためのさまざまなオプションが含まれています。

また、MFCを使えば、かなり複雑なダイアログボックスを数分で、しかも非常に簡単に作ることができます。

 
Alexey Navoykov:

そして、この目的には構造体を使うことができるのに、なぜ配列を使ってこんなにも変態的なことをするのでしょうか。また、これらの値はインデックスではなく、フィールド名でアクセスすることができます（これは多くの間違いを引き起こす可能性があります）。

その結果、2次元の配列ではなく、構造体の配列になります。 宣言は同じ簡潔さですが、シンプルさと信頼性ははるかに高く、さらに各フィールドが独自の型を持っているので、合理的にメモリを使用できます。 そして、OOPは全く関係ありません。

以下はその一例です。

いい解決策だと思います。しかし、この構造はカーネルに統合することはできません。私の技術でカーネルを作る場合、プロトタイプの要素で配列のループを作り、カーネルに書き換えればよいのですが、あなたのソリューションの場合、そのループが不可能です。

可能かもしれませんが、各要素を別の構造にラップする必要があります。また、グローバルスコープに表示するにはどうすればよいのでしょうか？どこに宣言すればいいのか...はっきりしないんです。

私のはシンプルです。要素のプロトタイプの配列。オブジェクトの すべてのプロパティは その中にある。配列そのものはグローバルです。アクセスは最もシンプルで、プログラムのどこからでも可能です。

 
ダブルスを使うことに抵抗はないのでしょうか？結局のところ、独自のメソッドを持つ複合オブジェクトでもある。オーソドックスなカーネルアレイに居場所はない！？見て、印象的だから（仮数、指数、符号）。
_NEW_OBJECT, тра-та-та-та-та-та, 3, 10, 1, тра-та-та-та-та-та
 
pavlick_:
ダブルスを使うことに抵抗はないのでしょうか？結局のところ、独自のメソッドを持つ複合オブジェクトでもある。オーソドックスなカーネルアレイに居場所はない!ほら、印象的でしょう（仮数、指数、符号）。

理解できない。

 

不要な構文やタンバリンを排除し、単純に要素のプロパティをグローバルなプロトタイプ配列に初期化する。

これは、要素のプロトタイプをKernelに書き換えるときに一度だけ使われます。

書き換えは単純なループで行われる。

その結果、ビルドの段階で、ユーザーが選択した要素のプロトタイプがKernelに含まれるようになる。

次に、カーネルの新しいサイクルが始まります。その中に、要素のプロパティのユーザー定義値を書いています。

最後に、すべての要素を含む完成されたユーザーウィンドウを含むカーネルを得ることができます。

 

私は、上記のようなプロセスを「コアづくりのプロセス」と呼んでいます。

コアができてから、「エンジン」が動き出す。

エンジンは、要素の仕組みを制御するコードです。

エンジンは、カーネルと一緒に働くようにしか訓練されていません。そのエンジンは、様々なイベント（主にOnChartEvent() から来る）です。

1234567891011...184
新しいコメント