記事"MetaTraderプログラムを簡単かつ迅速に開発するためのライブラリ(第1部)概念、データ管理および最初の結果"についてのディスカッション - ページ 3

新しいコメント
 
Stanislav Korotky:

今のところ」そのままにしておくと、ローカライゼーションを再設計する際に、多くのコードを変更しなければならなくなります。リソース」ライブラリやヘッダーから文字列を一度に接続することの何が難しいのか？

Artemは簡単な方法を探しているわけではないのだろう）さらに、ライブラリーの開発は、定期的にコードをリファクタリングしながら段階的に進めていくと彼は言った。

 
Stanislav Korotky:

今のところ」そのままにしておくと、ローカライゼーションを再設計する際に、多くのコードを変更しなければならなくなります。リソース」ライブラリやヘッダーから文字列を一度に接続することの難しさとは？

何事にも順番があります。ライブラリーを作っている段階では、まだメッセージクラスはありません。作成されれば、すべてがそうなる。私は機関車より先に走ろうとしているわけではなく、「単純なものから複雑なものへ」という原則を守っている：

取引、自動売買システム、取引戦略のテストに関するフォーラム

メタトレーダー用プログラムを簡単かつ迅速に作成するためのライブラリ（パート1）。コンセプト、データ整理、最初の結果"

Artyom Trishkin, 2019.02.27 19:25

さて、構造のリターンは、ユーザーのリクエストによる追加機能として計画されています - 純粋に利便性のためです。そこにさらにそれが表示されます。いずれにせよ -ライブラリは、変更の導入で、その作成のステップの説明と一緒に "オンザフライ "で作成されます。そこでさらに、「高くない」ものを作る方法が見られるだろう。

しかし、私はすでにそれを行っている。今、私はそれを構造的に説明し、同時に自分自身のためにすべてを整理しているところだ。

そして一般的に、私は「単純なものから複雑なものへ」というやり方には慣れているが、「次に何があるか」をあらかじめ考えている。


 
Artyom Trishkin:

何事にも順番がある。ライブラリーの作成段階では、まだメッセージクラスはない。ライブラリーが作成されれば、すべてがそうなる。私は 機関車の先を走って「単純なものから複雑なものへ」という原則を貫こうとしているわけではない：

それは読んだ。ただ、作業計画が まだローカライゼーションに至っていないのなら、なぜ今のまま入れる必要があったのか、ということだ。一般的に、オーナーはボスであり、質問は修辞的である。

 
Stanislav Korotky:

それは読みました。ただ、作業計画がまだローカライズに至っていないのなら、なぜ今のまま入れる必要があったのか、ということだ。ともあれ、ボスはボスで、修辞的な質問だ。

プランはとっくに描かれている。そして、私はそれを変えるつもりはない。これは最初の部分、つまり、詳細のない大まかなコンセプトの話に過ぎない。そして、もしあなたが注意深いなら、あなたの質問はとても奇妙だ。
ボディのルーフにハッチがないことを、あなたがまだ見たこともない車のフレームに主張するのはおかしい。
 
Artyom Trishkin:
プランはずっと前から決まっている。それを変えるつもりはない。これは最初の部分、つまりごく初歩の部分であり、詳細のない一般的なコンセプトについての話だ。そして、もしあなたが注目しているのなら、あなたの質問はとても奇妙だ。
車体のフレームについて、まだ見たこともない車体のルーフにハッチがないという主張をするのはおかしい。

車の例えを続けるなら、すでにウェバストのサンルーフが何らかの理由でフレームに取り付けられているが、これは全体のコンセプトとは関係なく、交換が必要になるだろう。質問は計画や車全体についてではなく、不必要な部分（現在不必要な作業、将来不必要な手直し）についてだった。

 
Stanislav Korotky:

車の例えを続けるなら、すでにウェバストのハッチが何らかの理由でフレームに取り付けられているが、これは全体のコンセプトとは関係なく、交換する必要がある。質問は計画や車全体についてではなく、不必要な部分（現在不必要な作業、将来不必要な手直し）についてだった。

デバッグの際、ログに何かを出力する必要がある場合、ログ・エントリーを出力するクラス全体をトンボ言語で書くのですか？特に、この出力を記事で見せる必要がある場合は？記事の中でデバッガを表示することはできません。一般的に、私は機関車の先を走らない。特に、そのクラスは計画されており、適切で文脈に沿ったところで記事の中で示されるでしょうから。
 
fxsaber:

構造体を返すにはコストがかかる。同じ理由で、CopyRatesはCopyCloseより数倍高い。

本当ですか？つまり、MqlRates フィールドをすべてコピーする必要があるなら、CopyTime、CopyOpen、CopyHigh...と8つの関数を順番に使うよりも、CopyRatesを使った ほうが効率的なはずだ。の8つの関数を順番に使うよりも効率的なはずだ。
 
alex_all:
本当ですか？つまり、すべてのMqlRates フィールドをコピーする必要がある場合、CopyTime、CopyOpen、CopyHigh...と8つの関数を順番に使うよりも、CopyRatesを使った ほうが効率的なはずだ。の8つの関数を順次使用するよりも効率的なはずです。

関数 CopyClose、CopyHigh、High[]、Low[]などに対して効率的だからです。バー全体を参照しなくても、特定のインジケータが使用される場所はたくさんあります。

 
alex_all:
本当ですか？つまり、すべてのMqlRates フィールドをコピーする必要がある場合、CopyTime、CopyOpen、CopyHigh...と8つの関数を順番に使うよりも、CopyRatesを使った ほうが効率的なはずだ。の8つの関数を順番に使うよりも効率的なはずだ。

それでも、オブジェクトへのポインターを渡し、そこからプログラムでそのオブジェクトのプロパティをすべて取得する方が、参照渡しでクラスに渡された構造体にオブジェクトのプロパティをすべてコピーするよりも速いだろう。

 
Artyom Trishkin:

それでも、オブジェクトへのポインタを渡し、そこからプログラムでそのオブジェクトのすべてのプロパティを取得する方が、参照によってクラスに渡される構造体にオブジェクトのすべてのプロパティをコピーするよりも速いだろう。

CopyRatesは 構造体へのデータの実コピーを行い、CopyOpen...ファミリーは仮想コピー（構造体の上書き）を行います。- は仮想（つまり既存の配列への参照の上書き）ですか？

ただ、プラットフォームに組み込まれた構造体を作成することは、速度をあまり落とさずにそれを扱うメカニズムが実装されていれば、理にかなっているということだ。

1234567
新しいコメント