アドバイザープロジェクト - ページ 6 1234567 新しいコメント Vasiliy Sokolov 2017.08.10 15:41 #51 Alexey Navoykov:文明世界では、リストが実行されるのは...MQLで文明的なライブラリを書けよ、話はそれからだ。このような叫びは何年も前から聞かされていましたが、突き詰めていくと、あからさまなボドクロ化が始まってしまうのです。MQはCObjectの リファレンスで本当にミスをした。彼らはそこにいてはいけない。そして、これらの参照は、CListのような非常に特殊なコンテナで使用される。しかし、エラーがないところは？文明的な言語とでも言うのでしょうか。Richter氏の評論を読むと、Object C#についてどう考えているのか、どのようなメソッドを含むべきでないのかがわかります。リヒターが正しいから、C#の利用を拒否すべきなのか？くだらない。だから、ここで溜飲を下げるのはやめて、最後に手続きジャングルに行ってください。 Alexey Navoykov 2017.08.10 16:16 #52 George Merts:そうですね、リストに定数オブジェクトを入れることはできませんね。 しかし、私は常にCObjectの機能を使っており、どの評論家もStandard Libraryのオブジェクトの配列やリストに似たものさえ提供していない。 "あるべき姿 "は、誰もが叫ぶ。しかし、何かを提案しても、突然、何もない。 実際に別のソフトウェアソリューションを提供している参加者でも、CObjectの代替品を提供しているわけではなく、全く使っていない、あるいはその機能をあまり使っていないケースが多く、「一箇所での実装」に注目していない。 そしてこれは、実装がかなり良いということである。 もし不良品なら、とっくに買い替えが提案されているはずです。通常、ネイティブCObjectは、他のすべてが標準ライブラリに基づいて いる場合に使用されます。特に、ソースを積極的に公開している企業は、外部ユーザーが使いやすいように、コードの統一や自作コードの削減、自作ライブラリの削減を行う傾向があります。しかし、自分のためのコーディングなのか、他人の都合のためのコーディングなのかは、誰もが自分で決めることです。しかし、多くの人は（私のように）自分なりの解決策を使っていて、それを他人に提供する必要性を感じていないだけなのでしょう。しかし、一般的には、MFCのような有名なライブラリをベースにした規格があったほうがいいと思います。だからこそ、私はMQをよく理解できません。なぜ彼らは、既製のソリューションを移植するのではなく、（非常に議論を呼んだ上に）自分たちで車輪を再発明しなければならなかったのでしょう。ただし、MQL言語自体にも同じことが言える )))しかし、原則的には、CObjectを拒否することを強制しているわけではなく、MQの非常にクールなCObjectがあるのに、誰かがCMyCobjectを使うべきだというフレーズに反応して、批判的な発言をしただけです :) 。 Alexey Navoykov 2017.08.10 16:30 #53 Vasiliy Sokolov:MQLで文明的なライブラリを書け、話はそれからだ。何年も前から叫んでいたのに、いざとなると露骨にボドコドコ言い出すんですね。まあ、自分のライブラリは自分で持っているんですけどね。それで、何を話したかったんですか？CObject MQのリファレンスで本当に失敗してしまった。いないに違いない。そして、これらの参照は、CListのような非常に特殊なコンテナで使用される。しかし、エラーがないところは？文明的な言語とでも言うのでしょうか。Richter氏の評論を読むと、Object C#についてどう考えているのか、どのようなメソッドを含むべきでないのかがわかります。リヒターが正しいから、C#の利用を拒否すべきなのか？くだらない。だから、ここで溜飲を下げるのはやめて、最後に手続きジャングルに行ってください。傲慢で失礼なことを言うな、お前個人に言ってるんじゃないんだぞ。リンクがぐちゃぐちゃ」については......そうですね、おかしいですね、もう全部塗った後ですからね。さっきからCObjectが すごいとか、ポインタすらデフォルトではそこで初期化されないとか、文字通り垂れ流していますが（少なくとも、まずは自分の言語のソースコードを勉強すべきでした）。とにかく、もうここであなたを中傷する意味はないと思っています。 Andrey Kisselyov 2017.08.10 16:46 #54 George Merts: でも、必ずしもOOPを 使う必要はないというのは、私も同感です。例えば、私はCDataProvider:pulic CDataProviderIクラス - Expert Advisorに時系列、指標、ターミナルと環境データを提供するデータプロバイダを持っています。Expert Advisorでは、多くのTSが存在し、それぞれがデータプロバイダーからタイムシリーズとインジケータへのポインタを受け取ります（各TSはタイムシリーズを作成する必要はありません。データプロバイダーは、必要なタイムシリーズがすでに存在すればポインタを提供し、まだ作成されていないタイムシリーズのみを作成します）。 データ提供者からインジケータを取得する必要がある場合 - インジケータ記述構造体に記入し、この構造体を指して、提供者にインジケータを要求します。 したがって、データプロバイダー内部の各インジケーターは、その構造を識別し（データプロバイダーは構造の抽象的なベースクラスしか「知らない」）、それに従って、データプロバイダーが作成する準備のできたインジケーターオブジェクトを作成できるようにしなければなりません。 しかし、新しい発想の指標を確認するためだけに、このようなプロジェクトを立ち上げるのは無理があります。そのため、このような新しい指標は、OOPを一切使わず、すべて「手書き」です。 しかし、Expert Advisorに有用なインジケータは、OOPを完全にサポートし、データプロバイダー内に作成するなど、「適切に」記述されています。 同じ指標を業務で使用する多くのTSの方にとって、大きな解決策になると思います。 15年ほど前、MT4に搭載されているすべてのインジケータを逆張りモードで取引できるかどうかテストしたところ、日足で利益を出せるものは1つしかありませんでした。 ほとんどのインジケータは内蔵のインジケータに基づいており、そのため取引結果はほぼすべて低くなります。トレーダーの最初の仕事は、予測精度やパターンの収益性について市場を調査することだと私は考えています。 を尊重します。 主なものは、あなたが行くと彼らのアイデアの実現を参照してください方向であなたを混乱させることはできません。 この全体のサーカスの目的は、離れて利益から、間違った方向に混乱させると指示することである。 Vasiliy Sokolov 2017.08.10 16:58 #55 Alexey Navoykov: さて、通常、通常のCObjectは、他のものもすべて標準ライブラリに基づいて いる場合に使用されます。特に、ソースコードを積極的に共有する人は、通常、統一を求めます。自作コードを削減しは、自社の図書館の数を減らす。を導入し、外部ユーザーの利便性を高めました。しかし、自分のためにコーディングするのか、他人の便宜のためにコーディングするのかは、誰もが自分で決めることです。さて、なぜ自分で書いた自転車ではなく、CObjectを使うべきなのか、という疑問に自分で答えてしまいましたね。なぜなら、「統一」「自作コードの削減」「自作ライブラリの削減」という言葉は、すべての開発者が目指すべきものだからです。これはプログラマーの聖域である。もちろん、標準ライブラリは時代遅れです。この言語ではジェネリックができるようになり、インターフェイスも登場します。しかし、旧来の図書館が機能しているので、良い意味で統一感があり、「善は急げ」と言われるように、良いものは良いのです。完璧なもの、最高のものは存在しないのだから、良いものを使うしかない。リンクがぐちゃぐちゃ」については......そうですね、もう全部書いてしまった後なので、おかしいですね。さっきからCObjectがすごいとか、ポインターがデフォルトで初期化されないとか、文字通り「くだらない」ことを言っていますが（そもそもソース言語くらい勉強すべきです）。一般的に、私はあなたを中傷する意味を理解していません。ここでは、誰もあなたの前にひれ伏すことはありません。あなたがここで私たちに「明かした」「隠された」知識は、昔から多くの人が知っていたことだと信じています。リンクの初期化については、論外です。あなたは自分が形式的に正しいことを知っているので、同じことを私の鼻にこすりつけようとします：数学を読む、NULLを学ぶ、などなど。でも、教えなくていいんです。あなたはかっこいい。全部持ってきたんだね。では、なぜビーズを投げるのですか？図書館に行く。0.5%速くなるかを確認する。 Georgiy Merts 2017.08.10 17:09 #56 Andrey Kisselyov: フラクタルやピンバーの指標もよく使われます。 同じ指標を取引に使う多くのトレーディングシステムにとって素晴らしいソリューションです。しかし、テストには適していません。だからこそ、必要に迫られて行うのです。 15年前、MT4ですべての指標を逆位置モードでの取引に適しているかテストしていたところ、日々利益を上げていたのはたった1つでした。いや、インジケーターの本質を正しく理解すればいいんです。指標は既製品の聖杯ではなく、値動きの特殊性を簡便に表現したものに過ぎない。したがって、「最終的な信号源」として扱うのではなく、あくまでも「信号の特徴」として、複合的に利用することが必要です。そしてこの場合、ほとんどのテストで多くの指標が必要になり始める。特にATRなどは、ほぼすべての場所で使っているので、Expert Advisorのテンプレートに標準化することをすでに考えています。MA MAもかなり頻繁に求められる指標です。フラクタル、ピンバー指標...。 Vasiliy Sokolov 2017.08.10 17:17 #57 George Merts:...しかし、常にOOPを使用 する必要性からは程遠いというのは同感です。例えば、CDataProvider:pulic CDataProviderIというクラスがあり、これはデータプロバイダーで、エキスパートにタイムシリーズ、インディケータ、ターミナル、環境データを提供する。Expert Advisorでは、多くのTSが存在し、それぞれがデータプロバイダーからタイムシリーズとインジケータへのポインタを受け取ります（各TSがタイムシリーズを作成する必要はありません。） データ提供者からインジケータを受け取る必要がある場合 - インジケータ記述構造体に記入し、この構造体を指して提供者にインジケータを要求します。 したがって、データプロバイダー内部の各インジケーターは、その構造を識別し（データプロバイダーは構造の抽象ベースクラスしか「知らない」）、それに従って、データプロバイダーが作成する準備のできたインジケーターオブジェクトを作成できるようにする必要があります。 しかし、もちろん新しい発想の指標を確認するためだけに、このプロジェクトを始めるのは合理的ではありません。そのため、このような新しい指標は、OOPを一切使わず、すべて「手書き」です。しかし、Expert Advisorに有用なインジケータであれば、OOPを完全にサポートし、dataprovider内に作成するなど、「適切に」記述されています。 追伸ところで、インジケータとデータプロバイダの場合、仮想化継承の利点があります。 インジケータパラメータの基本インターフェースCIndicatorParametersIがあり、このインターフェースの子孫が、必要なインジケータの実パラメータになります。インジケータを要求する際に、これらのパラメータを宣言し、データプロバイダに抽象インターフェースへのポインタを渡します。このため、データプロバイダー自身は、どのようなインジケータが要求されているのかさえも知りません。そして、このインジケータだけが、どのようなパラメータが渡されたかを知っており、渡されたオブジェクトから必要なパラメータを抽出するのです。 そのトリックは、dataprovider内部のほとんどすべての場所に、パラメータ（または指標）の単純な基本クラスがあることです。基本的なインターフェースの最も単純で最も一般的な機能だけが、dataproviderで利用可能です。これにより、（必要な場合の）コードの修正が簡単になり、データ提供者からの指標のコードに「手を加える」誘惑も生まれません。インジケーターを変更する場合、それはインジケーター内部だけで行われ、データプロバイダーはインジケーターのストレージに過ぎず、できることは最大で新しいインジケーターを作成することです。 複雑にしすぎているのでは？日付プロバイダはMetaTraderそのものです。つまり、date-providerは本当に必要なものではなく、データを扱うための便利なインターフェイスが必要なだけなのです。例えば、私のLiberaでは、最後のバーの始値を書くだけでいいのです。double open_price = WS.Open[0];WSの対象は常にそこにあり、手元で動作しているのです。その仕組みは、舞台裏に隠されています。それが、すべてのデータへのアクセスです:) s.o.p. OOPはシステムの使用の複雑さを減らすべきで、増やすべきではありません。簡単なチェックのために庭を作らなければ ならないと認めるなら、プロバイダとの建築に何か問題があるということです。つまり、いつも使いたいとは思わないものをプログラムしてしまっているのです。 Andrey Kisselyov 2017.08.10 17:21 #58 George Merts:いや、インジケーターの本質を正しく理解すればいいんです。インジケーターは既製品の聖杯ではなく、値動きの特異性を都合よく表現したものに過ぎない。したがって、「最終的な信号源」として扱うのではなく、あくまでも「信号の特徴」として、複合的に利用することが必要です。そしてこの場合、ほとんどのテストで多くの指標が必要になり始める。特にATRなどは、ほぼすべての場所で使っているので、Expert Advisorのテンプレートに標準化することをすでに考えています。MA MAもかなり頻繁に求められる指標です。フラクタル、ピンバー指標...。 私はATPを指標とは考えていません。ATPは一定期間の市場の平均的な変動率を示しており、エントリーシグナルとしては適していません（フィルターとして適用することはできますが、それ以上のものではありません）。 15年前の話ですが、今は相場観が少し変わりました。 を尊重します。 Georgiy Merts 2017.08.10 18:42 #59 Vasiliy Sokolov:必要以上に複雑にしているのでは？データプロバイダーはMetaTrader自身です。つまり、本当に必要なのはdate-providerではなく、データを扱うためのユーザーフレンドリーなインターフェイスだけなのです。例えば、私のLiberaでは、最後のバーの始値を書くだけでいいのです。WSの対象は常にそこにあり、手元で動作しているのです。その仕組みは、舞台裏に隠されています。これでデータへのアクセスはすべて完了です:) s.w. OOPは、システムを使用する際の複雑さを減らすべきであり、増やすべきではありません。そして、もしあなた自身が、簡単なチェックのために菜園を作る 必要があると認めるなら、それはあなたのISPアーキテクチャに何か問題があることを意味するのです。つまり、常に使いたいとは思わないものをプログラムしてしまっているのです。あなた（仮に「あなた」とします）のエントリー「WS.Open[0];" は、私のエントリ "m_tcMainContainer.Open(0)" とほとんど変わりません。WSオブジェクトの初期化で何か予備動作があるのでは？ 私の場合、bool _LoadMainTimeseriesToLocalContainer(uint uiNeedBuffer)関数を呼び出す 必要があります。Expert Advisorの各部分（入力のジェネレータ、トレイリングと出口のコントローラ、すなわち取引アクションを実行できるオブジェクト）には「Timeseries Container」オブジェクトがあり、実際には、これは追加のサービスオプションを持つOHLCSTVtVrタイムシリーズへのポインタです。 Expert Advisorには、異なるシンボルや異なるタイムフレームの多くの異なるコンテナが存在することができます。データ提供者の思想により、重複しないように配慮しています。現実には、すべての時系列がそこに格納され、コンテナは必要なものを指すだけだからです。私が理解しているように、WS（WareStore、おそらく？）はまだ私のデータプロバイダです。ただ、私のdataproviderは残りのデータ、つまりインディケータ、シンボル（CsymbolInfoオブジェクト）、ターミナル（CTerminalInfoオブジェクト）も集中させていて、チャートのコレクションも持っています。更新のたびに、（必要に応じて）時系列が更新される。ここでは、標準ライブラリのものに近い思想が採用されている。 MT4-5自体をデータプロバイダーと考え、我々のクラスはアクセスを提供するためだけに使用されるとすると、オープン価格への言及によると、1つの値に対してCopyOpen()関数を呼び出さなければならないことが判明しました - これは私には不合理に思えます。私は、プログラムのどの場所でも、すべての変数にフルアクセスすることは非常に不合理だと考えています。逆に、プログラムのそれぞれの場所で、その動作に必要な構造体とデータだけにアクセスするようにしています。それ以外のものは、アクセスできないようにしなければなりません。データプロバイダーの思想によって、私はこのアクセスをコントロールすることができます。 Georgiy Merts 2017.08.10 18:45 #60 Andrey Kisselyov: 私はこれを指標とは考えていません。これは一定期間の市場の平均変動率を示しており、エントリーシグナルとしては適していません（フィルターとして適用することはできますが、それ以上のものではありません）。 15年前の話ですが、今は相場観が少し変わりました。 謹んで申し上げます。ATRは指標としてカウントされない」ってどういうこと？ また、「エントリーシグナルとしてふさわしくない」とは、どういうことでしょうか？そして、このインジケーターだけを使って「volatility breakdown」エントリーをする私は馬鹿なのか・・・？ あなたには、インジケーターの本質を理解するための、あなたなりのこだわりがあるのではないでしょうか...。私にとってのインジケーターとは、時間によって何らかの可変値を生み出すことができるオブジェクトです。実は、普通のローソク足チャートの価格も指標になるのです。でも、あなたにとっては別のものなんですね...。その結果、私たちの理解も違ってきます。 1234567 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
文明世界では、リストが実行されるのは...
MQLで文明的なライブラリを書けよ、話はそれからだ。このような叫びは何年も前から聞かされていましたが、突き詰めていくと、あからさまなボドクロ化が始まってしまうのです。
MQはCObjectの リファレンスで本当にミスをした。彼らはそこにいてはいけない。そして、これらの参照は、CListのような非常に特殊なコンテナで使用される。しかし、エラーがないところは？文明的な言語とでも言うのでしょうか。Richter氏の評論を読むと、Object C#についてどう考えているのか、どのようなメソッドを含むべきでないのかがわかります。リヒターが正しいから、C#の利用を拒否すべきなのか？くだらない。だから、ここで溜飲を下げるのはやめて、最後に手続きジャングルに行ってください。
そうですね、リストに定数オブジェクトを入れることはできませんね。
しかし、私は常にCObjectの機能を使っており、どの評論家もStandard Libraryのオブジェクトの配列やリストに似たものさえ提供していない。
"あるべき姿 "は、誰もが叫ぶ。しかし、何かを提案しても、突然、何もない。
実際に別のソフトウェアソリューションを提供している参加者でも、CObjectの代替品を提供しているわけではなく、全く使っていない、あるいはその機能をあまり使っていないケースが多く、「一箇所での実装」に注目していない。 そしてこれは、実装がかなり良いということである。
もし不良品なら、とっくに買い替えが提案されているはずです。
通常、ネイティブCObjectは、他のすべてが標準ライブラリに基づいて いる場合に使用されます。特に、ソースを積極的に公開している企業は、外部ユーザーが使いやすいように、コードの統一や自作コードの削減、自作ライブラリの削減を行う傾向があります。しかし、自分のためのコーディングなのか、他人の都合のためのコーディングなのかは、誰もが自分で決めることです。
しかし、多くの人は（私のように）自分なりの解決策を使っていて、それを他人に提供する必要性を感じていないだけなのでしょう。しかし、一般的には、MFCのような有名なライブラリをベースにした規格があったほうがいいと思います。だからこそ、私はMQをよく理解できません。なぜ彼らは、既製のソリューションを移植するのではなく、（非常に議論を呼んだ上に）自分たちで車輪を再発明しなければならなかったのでしょう。ただし、MQL言語自体にも同じことが言える )))
しかし、原則的には、CObjectを拒否することを強制しているわけではなく、MQの非常にクールなCObjectがあるのに、誰かがCMyCobjectを使うべきだというフレーズに反応して、批判的な発言をしただけです :) 。
MQLで文明的なライブラリを書け、話はそれからだ。何年も前から叫んでいたのに、いざとなると露骨にボドコドコ言い出すんですね。
まあ、自分のライブラリは自分で持っているんですけどね。それで、何を話したかったんですか？
CObject MQのリファレンスで本当に失敗してしまった。いないに違いない。そして、これらの参照は、CListのような非常に特殊なコンテナで使用される。しかし、エラーがないところは？文明的な言語とでも言うのでしょうか。Richter氏の評論を読むと、Object C#についてどう考えているのか、どのようなメソッドを含むべきでないのかがわかります。リヒターが正しいから、C#の利用を拒否すべきなのか？くだらない。だから、ここで溜飲を下げるのはやめて、最後に手続きジャングルに行ってください。
傲慢で失礼なことを言うな、お前個人に言ってるんじゃないんだぞ。
リンクがぐちゃぐちゃ」については......そうですね、おかしいですね、もう全部塗った後ですからね。さっきからCObjectが すごいとか、ポインタすらデフォルトではそこで初期化されないとか、文字通り垂れ流していますが（少なくとも、まずは自分の言語のソースコードを勉強すべきでした）。とにかく、もうここであなたを中傷する意味はないと思っています。
でも、必ずしもOOPを 使う必要はないというのは、私も同感です。
例えば、私はCDataProvider:pulic CDataProviderIクラス - Expert Advisorに時系列、指標、ターミナルと環境データを提供するデータプロバイダを持っています。Expert Advisorでは、多くのTSが存在し、それぞれがデータプロバイダーからタイムシリーズとインジケータへのポインタを受け取ります（各TSはタイムシリーズを作成する必要はありません。データプロバイダーは、必要なタイムシリーズがすでに存在すればポインタを提供し、まだ作成されていないタイムシリーズのみを作成します）。
データ提供者からインジケータを取得する必要がある場合 - インジケータ記述構造体に記入し、この構造体を指して、提供者にインジケータを要求します。
したがって、データプロバイダー内部の各インジケーターは、その構造を識別し（データプロバイダーは構造の抽象的なベースクラスしか「知らない」）、それに従って、データプロバイダーが作成する準備のできたインジケーターオブジェクトを作成できるようにしなければなりません。
しかし、新しい発想の指標を確認するためだけに、このようなプロジェクトを立ち上げるのは無理があります。そのため、このような新しい指標は、OOPを一切使わず、すべて「手書き」です。 しかし、Expert Advisorに有用なインジケータは、OOPを完全にサポートし、データプロバイダー内に作成するなど、「適切に」記述されています。
15年ほど前、MT4に搭載されているすべてのインジケータを逆張りモードで取引できるかどうかテストしたところ、日足で利益を出せるものは1つしかありませんでした。 ほとんどのインジケータは内蔵のインジケータに基づいており、そのため取引結果はほぼすべて低くなります。トレーダーの最初の仕事は、予測精度やパターンの収益性について市場を調査することだと私は考えています。
を尊重します。
主なものは、あなたが行くと彼らのアイデアの実現を参照してください方向であなたを混乱させることはできません。 この全体のサーカスの目的は、離れて利益から、間違った方向に混乱させると指示することである。
さて、なぜ自分で書いた自転車ではなく、CObjectを使うべきなのか、という疑問に自分で答えてしまいましたね。なぜなら、「統一」「自作コードの削減」「自作ライブラリの削減」という言葉は、すべての開発者が目指すべきものだからです。これはプログラマーの聖域である。
もちろん、標準ライブラリは時代遅れです。この言語ではジェネリックができるようになり、インターフェイスも登場します。しかし、旧来の図書館が機能しているので、良い意味で統一感があり、「善は急げ」と言われるように、良いものは良いのです。完璧なもの、最高のものは存在しないのだから、良いものを使うしかない。
リンクがぐちゃぐちゃ」については......そうですね、もう全部書いてしまった後なので、おかしいですね。さっきからCObjectがすごいとか、ポインターがデフォルトで初期化されないとか、文字通り「くだらない」ことを言っていますが（そもそもソース言語くらい勉強すべきです）。一般的に、私はあなたを中傷する意味を理解していません。
ここでは、誰もあなたの前にひれ伏すことはありません。あなたがここで私たちに「明かした」「隠された」知識は、昔から多くの人が知っていたことだと信じています。リンクの初期化については、論外です。あなたは自分が形式的に正しいことを知っているので、同じことを私の鼻にこすりつけようとします：数学を読む、NULLを学ぶ、などなど。でも、教えなくていいんです。あなたはかっこいい。全部持ってきたんだね。では、なぜビーズを投げるのですか？図書館に行く。0.5%速くなるかを確認する。
フラクタルやピンバーの指標もよく使われます。 同じ指標を取引に使う多くのトレーディングシステムにとって素晴らしいソリューションです。しかし、テストには適していません。だからこそ、必要に迫られて行うのです。 15年前、MT4ですべての指標を逆位置モードでの取引に適しているかテストしていたところ、日々利益を上げていたのはたった1つでした。
いや、インジケーターの本質を正しく理解すればいいんです。指標は既製品の聖杯ではなく、値動きの特殊性を簡便に表現したものに過ぎない。したがって、「最終的な信号源」として扱うのではなく、あくまでも「信号の特徴」として、複合的に利用することが必要です。そしてこの場合、ほとんどのテストで多くの指標が必要になり始める。特にATRなどは、ほぼすべての場所で使っているので、Expert Advisorのテンプレートに標準化することをすでに考えています。MA MAもかなり頻繁に求められる指標です。フラクタル、ピンバー指標...。
...
しかし、常にOOPを使用 する必要性からは程遠いというのは同感です。
例えば、CDataProvider:pulic CDataProviderIというクラスがあり、これはデータプロバイダーで、エキスパートにタイムシリーズ、インディケータ、ターミナル、環境データを提供する。Expert Advisorでは、多くのTSが存在し、それぞれがデータプロバイダーからタイムシリーズとインジケータへのポインタを受け取ります（各TSがタイムシリーズを作成する必要はありません。）
データ提供者からインジケータを受け取る必要がある場合 - インジケータ記述構造体に記入し、この構造体を指して提供者にインジケータを要求します。
したがって、データプロバイダー内部の各インジケーターは、その構造を識別し（データプロバイダーは構造の抽象ベースクラスしか「知らない」）、それに従って、データプロバイダーが作成する準備のできたインジケーターオブジェクトを作成できるようにする必要があります。
しかし、もちろん新しい発想の指標を確認するためだけに、このプロジェクトを始めるのは合理的ではありません。そのため、このような新しい指標は、OOPを一切使わず、すべて「手書き」です。しかし、Expert Advisorに有用なインジケータであれば、OOPを完全にサポートし、dataprovider内に作成するなど、「適切に」記述されています。
追伸
ところで、インジケータとデータプロバイダの場合、仮想化継承の利点があります。 インジケータパラメータの基本インターフェースCIndicatorParametersIがあり、このインターフェースの子孫が、必要なインジケータの実パラメータになります。インジケータを要求する際に、これらのパラメータを宣言し、データプロバイダに抽象インターフェースへのポインタを渡します。このため、データプロバイダー自身は、どのようなインジケータが要求されているのかさえも知りません。そして、このインジケータだけが、どのようなパラメータが渡されたかを知っており、渡されたオブジェクトから必要なパラメータを抽出するのです。
そのトリックは、dataprovider内部のほとんどすべての場所に、パラメータ（または指標）の単純な基本クラスがあることです。基本的なインターフェースの最も単純で最も一般的な機能だけが、dataproviderで利用可能です。これにより、（必要な場合の）コードの修正が簡単になり、データ提供者からの指標のコードに「手を加える」誘惑も生まれません。インジケーターを変更する場合、それはインジケーター内部だけで行われ、データプロバイダーはインジケーターのストレージに過ぎず、できることは最大で新しいインジケーターを作成することです。
複雑にしすぎているのでは？日付プロバイダはMetaTraderそのものです。つまり、date-providerは本当に必要なものではなく、データを扱うための便利なインターフェイスが必要なだけなのです。例えば、私のLiberaでは、最後のバーの始値を書くだけでいいのです。
WSの対象は常にそこにあり、手元で動作しているのです。その仕組みは、舞台裏に隠されています。それが、すべてのデータへのアクセスです:)
s.o.p. OOPはシステムの使用の複雑さを減らすべきで、増やすべきではありません。簡単なチェックのために庭を作らなければ ならないと認めるなら、プロバイダとの建築に何か問題があるということです。つまり、いつも使いたいとは思わないものをプログラムしてしまっているのです。いや、インジケーターの本質を正しく理解すればいいんです。インジケーターは既製品の聖杯ではなく、値動きの特異性を都合よく表現したものに過ぎない。したがって、「最終的な信号源」として扱うのではなく、あくまでも「信号の特徴」として、複合的に利用することが必要です。そしてこの場合、ほとんどのテストで多くの指標が必要になり始める。特にATRなどは、ほぼすべての場所で使っているので、Expert Advisorのテンプレートに標準化することをすでに考えています。MA MAもかなり頻繁に求められる指標です。フラクタル、ピンバー指標...。
15年前の話ですが、今は相場観が少し変わりました。
を尊重します。
必要以上に複雑にしているのでは？データプロバイダーはMetaTrader自身です。つまり、本当に必要なのはdate-providerではなく、データを扱うためのユーザーフレンドリーなインターフェイスだけなのです。例えば、私のLiberaでは、最後のバーの始値を書くだけでいいのです。
WSの対象は常にそこにあり、手元で動作しているのです。その仕組みは、舞台裏に隠されています。これでデータへのアクセスはすべて完了です:)
s.w. OOPは、システムを使用する際の複雑さを減らすべきであり、増やすべきではありません。そして、もしあなた自身が、簡単なチェックのために菜園を作る 必要があると認めるなら、それはあなたのISPアーキテクチャに何か問題があることを意味するのです。つまり、常に使いたいとは思わないものをプログラムしてしまっているのです。あなた（仮に「あなた」とします）のエントリー「WS.Open[0];" は、私のエントリ "m_tcMainContainer.Open(0)" とほとんど変わりません。
WSオブジェクトの初期化で何か予備動作があるのでは？
私の場合、bool _LoadMainTimeseriesToLocalContainer(uint uiNeedBuffer)関数を呼び出す 必要があります。
Expert Advisorの各部分（入力のジェネレータ、トレイリングと出口のコントローラ、すなわち取引アクションを実行できるオブジェクト）には「Timeseries Container」オブジェクトがあり、実際には、これは追加のサービスオプションを持つOHLCSTVtVrタイムシリーズへのポインタです。
Expert Advisorには、異なるシンボルや異なるタイムフレームの多くの異なるコンテナが存在することができます。データ提供者の思想により、重複しないように配慮しています。現実には、すべての時系列がそこに格納され、コンテナは必要なものを指すだけだからです。
私が理解しているように、WS（WareStore、おそらく？）はまだ私のデータプロバイダです。ただ、私のdataproviderは残りのデータ、つまりインディケータ、シンボル（CsymbolInfoオブジェクト）、ターミナル（CTerminalInfoオブジェクト）も集中させていて、チャートのコレクションも持っています。更新のたびに、（必要に応じて）時系列が更新される。ここでは、標準ライブラリのものに近い思想が採用されている。
MT4-5自体をデータプロバイダーと考え、我々のクラスはアクセスを提供するためだけに使用されるとすると、オープン価格への言及によると、1つの値に対してCopyOpen()関数を呼び出さなければならないことが判明しました - これは私には不合理に思えます。
私は、プログラムのどの場所でも、すべての変数にフルアクセスすることは非常に不合理だと考えています。逆に、プログラムのそれぞれの場所で、その動作に必要な構造体とデータだけにアクセスするようにしています。それ以外のものは、アクセスできないようにしなければなりません。データプロバイダーの思想によって、私はこのアクセスをコントロールすることができます。
私はこれを指標とは考えていません。これは一定期間の市場の平均変動率を示しており、エントリーシグナルとしては適していません（フィルターとして適用することはできますが、それ以上のものではありません）。
15年前の話ですが、今は相場観が少し変わりました。
謹んで申し上げます。
ATRは指標としてカウントされない」ってどういうこと？
また、「エントリーシグナルとしてふさわしくない」とは、どういうことでしょうか？そして、このインジケーターだけを使って「volatility breakdown」エントリーをする私は馬鹿なのか・・・？
あなたには、インジケーターの本質を理解するための、あなたなりのこだわりがあるのではないでしょうか...。私にとってのインジケーターとは、時間によって何らかの可変値を生み出すことができるオブジェクトです。実は、普通のローソク足チャートの価格も指標になるのです。でも、あなたにとっては別のものなんですね...。その結果、私たちの理解も違ってきます。