PLOの諸経費 - ページ 4 1234567 新しいコメント fxsaber 2017.07.06 20:07 #31 George Merts:私の経験では、必要だと思います。 私は5年ほど前、当時はMT4でこの方法をとりました。(というのも、当時はMT4とMT5でMQLの実装が大きく異なっていたため、インターフェースや継承について悩むのが面倒だったからです）。 その結果、その誤りを理解するに至りました。 これは「知恵」ではなく、極めて妥当な制限、一種の「愚直さ」なんですね。何百もの変数がそれぞれ何を担っているかを常に覚えているのであれば、カプセル化は必要ないでしょう。そんな覚えはないし、プログラムの各ブロックで利用できるエンティティはできるだけ少ない方がいい。 MQL4がOOPで登場すると同時に、私は自分の開発したものをすべてインターフェースに基づいた一つの形に変換し始めたのです。 MQL4オーダーシステムより便利なものは、まだ思いつきません。例があれば、ぜひ見せてください。私が見たすべてのトレーディングAPIは、MQL4と比較して巨大なものに見えます。また、不器用でもある。 Alexey Volchanskiy 2017.07.06 23:03 #32 fxsaber:MQL4のオーダーシステムほど便利な ものは思いつきません。例があれば、ぜひ見せてください。私が見たすべてのトレーディングAPIは、MQL4と比較すると巨大に見えます。しかも、不器用なんです。どんないいことがあるかというと、各パラメーターは別々の関数で描かなければならないのです。ティックのように、リクエストによってすべてのパラメータを含む構造体を受け取る方が論理的である。 Georgiy Merts 2017.07.07 07:07 #33 fxsaber:MQL4のオーダーシステムほど便利なものは思いつきません。例があれば、ぜひ見せてください。私が見たすべてのトレーディングAPIは、MQL4と比較すると巨大に見えます。しかも、不器用なんです。どういうことですか？ 注文の真髄は？そうですね、かなり便利です。 しかし、このシステムにOOPを適用するだけで、最大の「勝利」が得られると私は考えています。例えば、注文で構成されるMT4ポジションとMT5ポジションの両方を提供し、ヘッジ条件やネッティング条件に関係なく、同じインターフェースを持っているとします。 私見ですが、Select()関数で取得した注文オブジェクト（またはMT5のポジション）のリストがあり、関数で対応する「環境状態」（同じ関数で取得）よりも、注文のプロパティを対応する方がはるかに論理的で理解しやすいと思います。 最も興味深いのは、一度に複数の注文を追跡する必要がある場合、この場合、手続き的アプローチは必然的に「擬似オブジェクト」アプローチになります。OnTick()を入力するときに更新すべき注文に関する情報の配列を作成し、注文オブジェクトへのOOP-ポインタと同様に、配列内のインデックスで注文データを操作しなければならないのです。さらに、履歴のある注文と有効な注文を同時に扱う場合、履歴のある注文のインターフェイスが有効な注文の後継となるため、OOPアプローチによって優位に立つことができます。また、手続き的なアプローチでは、履歴のあるオーダーとアクティブなオーダーが異なる機能で扱われることになり、利便性が大きく損なわれてしまいます。 fxsaber 2017.07.07 07:49 #34 Alexey Volchanskiy: 各パラメータを別々の関数で引っ張る必要があるのが良い点です。ティックのように、要求に応じてすべてのパラメータを含む構造体を取得するのが論理的でしょう。Order.TakeProfitとOrderTakeProfit()の入力は同じです。最初のものはオブジェクトを保存する可能性があるだけで、2番目のものは関連性を持っています。格納の必要性に遭遇するのはごく稀で、TSではありません。そして、そこで構造を作るのは問題ない。私自身は、なぜ開発者が注文構造の返却を行わず、関数を通じて各フィールドを別々に残したのか不思議に思いました（履歴についても毎回チケットが必要です）。一般的に、MQL4-APIに本当に問題があるとは思えません（MT4/5に限らず動作するのかもしれません）。 fxsaber 2017.07.07 08:08 #35 George Merts:どういうことですか？ オーダーメイドの真髄は？そうですね、かなり便利です。 しかし、このシステムにOOPを適用するだけで、--私の考えでは--最大の「勝利」を得ることができるのです。例えば、注文で構成されるMT4ポジションとMT5ポジションの両方を与え、それがヘッジかネッティングかに関係なく、同じインターフェースを持っているとしましょう。自分には自分のラップがあり、相手には相手のラップがある。MQL4よりも便利なラッパーを作ることはできないか、ということでした。 関数でアクセスする「環境の状態」（同じ関数で取得）よりも、Select()関数で取得した注文オブジェクト（またはMT5のポジション）のリストがあり、注文プロパティにアクセスする方が、はるかに論理的で理解しやすいと私は考えています。最も興味深いのは、一度に複数の注文を追跡する必要がある場合、この場合、手続き的アプローチは必然的に「擬似オブジェクト」アプローチにつながるので、OnTick()に入るときに更新すべき注文に関する情報の配列を作成し、注文オブジェクトへのOOPポインタを扱うのと同じ方法で配列内のインデックスで注文データを処理しなければならないことです。前の記事で書きました。また、履歴のある注文と有効な注文を同時に扱う場合、履歴のある注文のインタフェースは有効な注文の継承者であるため、OOPアプローチは有利となります。 関数の大部分は共通です。また、手続き的なアプローチでは、ヒストリカルオーダーとアクティブオーダーを異なる関数で処理することになり、利便性が大きく損なわれてしまいます。さて、MQL4では、履歴は同じ関数で処理されます（OrdersHistoryTotalはカウントされません）。MQL4-APIよりも独自のトレードAPIが明らかに優れているコード例があると良いですね。私自身は、ほとんどすべての場面でOOPを使っています。また、特定の仕事では、トレードラッピングをすることもあります。しかし、ある特定の作業に使うには非常に便利ですが、万能ではありません。しかし、やはり普遍的な取引APIを比較したい。 Alexey Volchanskiy 2017.07.07 08:19 #36 fxsaber:私自身は、開発者がなぜ注文の返送を構造体にせず、関数で各項目を個別に残したのか（履歴も毎回チケットが必要）疑問に思っていました。 理由は、600番台のビルド以前のMT4には構造がなかったからです ))。そして、新しいMQL4が登場したのは、2013年の初めのどこかでした。 fxsaber 2017.07.07 08:50 #37 Alexey Volchanskiy: Дело в том, что в МТ4 до 600-го билда не было структур )) А новый MQL4 появился где-то в начале 2013 г.MT5では構造体はあったが、関数によるリターンはまだあった。 トレーディング、自動売買システム、ストラテジーテストに関するフォーラム OOPのためのオーバーヘッド fxsaber さん 2017.07.07 08:08 質問は違いますが、MQL4よりも便利なラッパーを作ることは可能なのでしょうか？ Alexey Volchanskiy 2017.07.07 10:27 #38 fxsaber:MT5では構造体があったが、とにかく関数で返す。伝統を壊さないと決めたのかもしれないが、そうすべきだったのだ。証券会社のサーバーからダウンロードしたデータならわかるが、ローカルで、即座に取られるのだから、すぐに構造を埋めることができるだろう fxsaber 2017.07.07 10:49 #39 Alexey Volchanskiy: 本来であれば、伝統を壊さないようにと考えたのだろう。DCサーバーからダウンロードしたデータならわかるが、ローカルで、瞬時に撮影しているのだから、すぐに構造を埋めることができるだろうそうです。SELECTでは、隠された構造体の1つのインスタンスを埋めるだけで、そのフィールドはconst（読み取り専用）関数を通してのみアクセス可能です。おそらく、トレーディングAPIカーネルで唯一疑問のある判断でしょう。それ以外は文句のつけようがないくらいです。 Andrei01 2017.07.07 12:38 #40 fxsaber:はい、SELECT が使用されると、const(read-only) 関数を介してのみフィールドにアクセスできる隠し構造の 1 つのインスタンスが満たされます。 これは、この構造へのアクセスを制限するためです。 1234567 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
私の経験では、必要だと思います。
私は5年ほど前、当時はMT4でこの方法をとりました。(というのも、当時はMT4とMT5でMQLの実装が大きく異なっていたため、インターフェースや継承について悩むのが面倒だったからです）。 その結果、その誤りを理解するに至りました。 これは「知恵」ではなく、極めて妥当な制限、一種の「愚直さ」なんですね。何百もの変数がそれぞれ何を担っているかを常に覚えているのであれば、カプセル化は必要ないでしょう。そんな覚えはないし、プログラムの各ブロックで利用できるエンティティはできるだけ少ない方がいい。
MQL4がOOPで登場すると同時に、私は自分の開発したものをすべてインターフェースに基づいた一つの形に変換し始めたのです。
MQL4オーダーシステムより便利なものは、まだ思いつきません。例があれば、ぜひ見せてください。
私が見たすべてのトレーディングAPIは、MQL4と比較して巨大なものに見えます。また、不器用でもある。
MQL4のオーダーシステムほど便利な ものは思いつきません。例があれば、ぜひ見せてください。
私が見たすべてのトレーディングAPIは、MQL4と比較すると巨大に見えます。しかも、不器用なんです。
どんないいことがあるかというと、各パラメーターは別々の関数で描かなければならないのです。ティックのように、リクエストによってすべてのパラメータを含む構造体を受け取る方が論理的である。
MQL4のオーダーシステムほど便利なものは思いつきません。例があれば、ぜひ見せてください。
私が見たすべてのトレーディングAPIは、MQL4と比較すると巨大に見えます。しかも、不器用なんです。
どういうことですか？
注文の真髄は？そうですね、かなり便利です。
しかし、このシステムにOOPを適用するだけで、最大の「勝利」が得られると私は考えています。例えば、注文で構成されるMT4ポジションとMT5ポジションの両方を提供し、ヘッジ条件やネッティング条件に関係なく、同じインターフェースを持っているとします。
私見ですが、Select()関数で取得した注文オブジェクト（またはMT5のポジション）のリストがあり、関数で対応する「環境状態」（同じ関数で取得）よりも、注文のプロパティを対応する方がはるかに論理的で理解しやすいと思います。
最も興味深いのは、一度に複数の注文を追跡する必要がある場合、この場合、手続き的アプローチは必然的に「擬似オブジェクト」アプローチになります。OnTick()を入力するときに更新すべき注文に関する情報の配列を作成し、注文オブジェクトへのOOP-ポインタと同様に、配列内のインデックスで注文データを操作しなければならないのです。
さらに、履歴のある注文と有効な注文を同時に扱う場合、履歴のある注文のインターフェイスが有効な注文の後継となるため、OOPアプローチによって優位に立つことができます。また、手続き的なアプローチでは、履歴のあるオーダーとアクティブなオーダーが異なる機能で扱われることになり、利便性が大きく損なわれてしまいます。
各パラメータを別々の関数で引っ張る必要があるのが良い点です。ティックのように、要求に応じてすべてのパラメータを含む構造体を取得するのが論理的でしょう。
Order.TakeProfitとOrderTakeProfit()の入力は同じです。最初のものはオブジェクトを保存する可能性があるだけで、2番目のものは関連性を持っています。格納の必要性に遭遇するのはごく稀で、TSではありません。そして、そこで構造を作るのは問題ない。
私自身は、なぜ開発者が注文構造の返却を行わず、関数を通じて各フィールドを別々に残したのか不思議に思いました（履歴についても毎回チケットが必要です）。
一般的に、MQL4-APIに本当に問題があるとは思えません（MT4/5に限らず動作するのかもしれません）。
どういうことですか？
オーダーメイドの真髄は？そうですね、かなり便利です。
しかし、このシステムにOOPを適用するだけで、--私の考えでは--最大の「勝利」を得ることができるのです。例えば、注文で構成されるMT4ポジションとMT5ポジションの両方を与え、それがヘッジかネッティングかに関係なく、同じインターフェースを持っているとしましょう。
自分には自分のラップがあり、相手には相手のラップがある。MQL4よりも便利なラッパーを作ることはできないか、ということでした。
関数でアクセスする「環境の状態」（同じ関数で取得）よりも、Select()関数で取得した注文オブジェクト（またはMT5のポジション）のリストがあり、注文プロパティにアクセスする方が、はるかに論理的で理解しやすいと私は考えています。
最も興味深いのは、一度に複数の注文を追跡する必要がある場合、この場合、手続き的アプローチは必然的に「擬似オブジェクト」アプローチにつながるので、OnTick()に入るときに更新すべき注文に関する情報の配列を作成し、注文オブジェクトへのOOPポインタを扱うのと同じ方法で配列内のインデックスで注文データを処理しなければならないことです。
前の記事で書きました。
また、履歴のある注文と有効な注文を同時に扱う場合、履歴のある注文のインタフェースは有効な注文の継承者であるため、OOPアプローチは有利となります。 関数の大部分は共通です。また、手続き的なアプローチでは、ヒストリカルオーダーとアクティブオーダーを異なる関数で処理することになり、利便性が大きく損なわれてしまいます。
さて、MQL4では、履歴は同じ関数で処理されます（OrdersHistoryTotalはカウントされません）。
MQL4-APIよりも独自のトレードAPIが明らかに優れているコード例があると良いですね。私自身は、ほとんどすべての場面でOOPを使っています。また、特定の仕事では、トレードラッピングをすることもあります。しかし、ある特定の作業に使うには非常に便利ですが、万能ではありません。しかし、やはり普遍的な取引APIを比較したい。
私自身は、開発者がなぜ注文の返送を構造体にせず、関数で各項目を個別に残したのか（履歴も毎回チケットが必要）疑問に思っていました。
Alexey Volchanskiy:
Дело в том, что в МТ4 до 600-го билда не было структур )) А новый MQL4 появился где-то в начале 2013 г.
MT5では構造体はあったが、関数によるリターンはまだあった。
トレーディング、自動売買システム、ストラテジーテストに関するフォーラム
OOPのためのオーバーヘッド
fxsaber さん 2017.07.07 08:08
質問は違いますが、MQL4よりも便利なラッパーを作ることは可能なのでしょうか？
MT5では構造体があったが、とにかく関数で返す。
伝統を壊さないと決めたのかもしれないが、そうすべきだったのだ。
証券会社のサーバーからダウンロードしたデータならわかるが、ローカルで、即座に取られるのだから、すぐに構造を埋めることができるだろう
本来であれば、伝統を壊さないようにと考えたのだろう。
DCサーバーからダウンロードしたデータならわかるが、ローカルで、瞬時に撮影しているのだから、すぐに構造を埋めることができるだろう
そうです。SELECTでは、隠された構造体の1つのインスタンスを埋めるだけで、そのフィールドはconst（読み取り専用）関数を通してのみアクセス可能です。
おそらく、トレーディングAPIカーネルで唯一疑問のある判断でしょう。それ以外は文句のつけようがないくらいです。
はい、SELECT が使用されると、const(read-only) 関数を介してのみフィールドにアクセスできる隠し構造の 1 つのインスタンスが満たされます。