'Ask' - function not defined Impulse.mqh 51 20
'Ask' - function not defined Impulse.mqh 51 28
'PendingOrders' - undeclared identifier Impulse.mqh 56 16
'GetOrder' - object pointer expected Impulse.mqh 58 44
'IsMain' - member function not defined Impulse.mqh 59 34
'Modify' - member function not defined Impulse.mqh 66 19
'Delete' - member function not defined Impulse.mqh 69 19
'Bid' - function not defined Impulse.mqh 85 20
'Bid' - function not defined Impulse.mqh 85 28
'PendingOrders' - undeclared identifier Impulse.mqh 90 16
'GetOrder' - object pointer expected Impulse.mqh 92 44
'IsMain' - member function not defined Impulse.mqh 93 34
'Modify' - member function not defined Impulse.mqh 100 19
'Delete' - member function not defined Impulse.mqh 103 19
'Bid' - function not defined Impulse.mqh 118 23
'Bid' - function not defined Impulse.mqh 118 31
'Bid' - function not defined Impulse.mqh 124 7
'Ask' - function not defined Impulse.mqh 136 23
'Ask' - function not defined Impulse.mqh 136 31
'Ask' - function not defined Impulse.mqh 142 7
20 error(s), 0 warning(s) 21 1
constメソッドへの偏り。私はC#のプログラマーになったが、そこではこの修飾子が課す制限は有効ではないため、存在しない。
私は素朴に、この修飾子はコンパイル時にコンパイラに、より最適なネイティブ・コードを作成するよう指示するものだとも思っていたのだが......。
私自身は自己制御のために使っている。
ストラテジー・テスターの 主な時間は、そのインフラストラクチャの作業（バーのスクロール、取引環境のエミュレーションなど）に費やされます。
一方、プロファイリングにより、CSTartegy の主なリソースを消費するメソッドは BuyInit、SellInit、BuySupport、SellSupport メソッド、すなわち Expert Advisor のロジックそのものであることがわかりました。他のすべてのストラッピングは、最適な方法でフラットコードにうまくコンパイルされます。これが高レベルのOOPプログラミングが正当化される理由です。
多くのルールと重いインフラストラクチャを持つ多かれ少なかれ複雑なExpert Advisorでは、最初のフラットな形式（関数やOOPなし）でプログラミングすると、プログラマーのエラーは避けられず、その結果、そのようなExpert AdvisorのパフォーマンスはOOPを使用した場合よりもさらに低下することに注意してください。アセンブラの時代は終わった。コンパイラーは、最適化のある分野ではとっくに人間に勝っている。最小限のインターフェースと優れた管理性を備えた、当初は有能でスケーラブルなアーキテクチャを定義するのは人間に任されているのだ。
。
私は素朴に、この修飾子はコンパイル時に、より最適なネイティブ・コードを作成するようコンパイラに指示するものだとも思っていたのだが......。
私自身、自己制御のために使っている。
私は手も足もOOPに賛成だ。マルチシンボルのOnTickのように、松葉杖のような解決策だけが隠されていない限りは。マルチシンボルのOnTickのように、松葉杖のような解決策が隠されていない限りは。
残念ながら、ユーザーレベルでは何もできない。CStrtategyのOnTickは多価ですが、その多価もまた松葉杖によってエミュレートされています。イベントが発生するたびに、別の商品のティックが要求され、それが変更された場合、その商品に対して新しいOnTickイベントが発生します。ところで、FORTSでは、CStrategyは OnBookEventイベントのおかげで、真に多通貨のOnTickを提供します。しかし、これもテスターで作業する場合のエミュレーションです。
もう一つの選択肢は、CStrategyにリソース・インジケータを提供することです。CStrategy は起動時に、必要なシンボルでこのインジケータのインスタンスを起動し、そこから新しいティック到着のイベントを受け取ります。その後、OnTick CStrategy に変換されます。これは古典的なひつぎですが、実装全体は見事に舞台裏に隠されており、これらのティックがどのように受信されたかを知らなくても、どのストラテジーも統一された方法で動作します。
残念ながら、ここではユーザー・レベルでは何もできない。CStrtategyのOnTickはマルチカレンシーですが、そのマルチカレンシーも松葉杖によってエミュレートされています。単純に、各入力イベントで別の商品のティックが要求され、それが変更された場合、この商品に対して新しいOnTickイベントが生成されます。ところでFORTSでは、CStrategyがOnBookEventイベントによって、真に多通貨のOnTickを提供しています。しかし繰り返しますが、これはテスターで作業しているときのエミュレーションです。
残念ながら、この方法ではティックを見逃します。
もう一つの選択肢は、CStrategyにリソース・インジケータを提供することです。CStrategy は起動時に、必要なシンボルでこのインジケータのインスタンスを起動し、新しいティック到着のイ ベントをこのインジケータから受け取ります。その後、OnTick CStrategy に変換されます。これは古典的な松葉杖の亜種ですが、実装全体は見事に舞台裏に隠されており、これらのティックがどのように受信されたかを知ることなく、どのストラテジーも統一された方法で動作します。
残念ながら、このアプローチはダニを見逃す。
そう、このオプションは開発者に認められている。しかし、IMHOは、最適化されたテスターのリソースが、他のプラットフォーム向けの最も単純なタスクに費やされていることを考えると、ひどく不便に思える。OOPは確かに、その不便さを見事に隠している。ペンダントに興味があるのですが、インパルスには多くのデータが欠けています。それとも自分で入力しなければならないのでしょうか？
ペンダントに興味があるのですが、インパルスには多くのデータが欠けています。それとも自分で入力しなければならないのでしょうか？
わからないことがあれば、このスレッドで質問してください。