無効なリクエスト - 始めたばかりで理解できない... - ページ 7 12345678 新しいコメント --- 2012.11.19 11:23 #61 papaklass:私の投稿は、なぜ標準ライブラリを 使わないのかという疑問に対する答えです 実は、私もそうなんです。でも、その理由は、私がMKよりずっと早くクラスを作ったからです。と、クラス内のメタドの冗長性に開発者の注意を喚起する試みです。 ラッパーに対する考え方が違うだけで、クラス設計や取引構造のロジックも違いますから、好みの問題でしょう。------------------------例えば、10008 -> 10012のような普遍的な処理方法はあるのでしょうか? 例えば、Expert Advisorの前後の動作とは無関係に、です。 この注文の処理結果はどうなるのでしょうか? Valerii Mazurenko 2012.11.19 11:40 #62 未使用の関数は、最終的なファイルから除外されるようなものです。もうひとつは、ほとんどの場合、「非ユニバーサル」コードの方がユニバーサルコードより速いという ことです(たとえばEAはより速く最適化され、クラウドの報酬は少し低くなります)。 Renat Fatkhullin 2012.11.19 11:42 #63 最適化コンパイラ+大量インライン化もお忘れなく。 コードの中で呼び出される関数だけを取り出し、それ以外は最適化の際にスキップされます。つまり、61個のメソッドを持つクラスのうち、3個だけ使用する場合、含まれるのは3個のメソッドのコードである。 インライン関数では、関数自体のサイズが小さいことと、コード全般の最適 化を考慮し、シンプルでフラットなコードを実現しています。 --- 2012.11.19 13:02 #64 papaklass: したがって、あるティックでポジションが開かれなければ、次のティックで開かれることになるので、この場合(10008→10012)には興味がないのです。Expert Advisorのロジックでポジションを開く 必要がある場合は、ほとんどの場合、ポジションを開くようにコードを構築するよう心がけています。次のティックで開くか、10ティック後に開くか。というのは、まさにその通りです。そして、エラー処理の問題に戻りますが、標準ライブラリに欠けているものは何でしょうか?エラー処理/解析の方向で、どのような改良を加えたいのだろうか? --- 2012.11.19 13:40 #65 papaklass:資金量以上のロットでポジションを建てる場合、または保留注文を出す場合、現在価格からの最小許容ステップを維持しない、またはポジションの方向を 考慮せずにストップを置く場合。 また、このような状況の処理、プログラマーの注文の不備をライブラリ自身が修正するというのはどういうことでしょうか。 つまり、図書館の判断で停車駅を逆転させたり、ロットを変更したりするのですか?それとも、適切なコードを送信して、プロジェクターに間違った注文を知らせるのでしょうか? Renat Fatkhullin 2012.11.19 13:44 #66 sergeev:といった状況を処理することで、プログラマーの注文の不備をライブラリ自身が修正するというのはどういうことなのでしょうか? つまり、図書館が自らの判断で停車駅を逆転させたり、ロットを変更したりするように? あと2、3回無邪気に質問すれば、papaklassは何かを推測し、疑い始めるだろう...。 --- 2012.11.19 14:02 #67 ただ、プログラマーによって「必要性と充足感」の認識が異なるため、機能拡張に対する疑問が生じるのです。推測のままでいるより、完全にクリアにしたほうがいいのです。 --- 2012.11.19 14:16 #68 papaklass: もう一度言いますが、私は誰も納得させることができないのです。ビブリオでいいと思うんだから、そのままでいいじゃないですか。このような議論を経ても、私はこの図書館を利用しない。私一人でいいんですか?アレクサンダーさん、あなただけではありません。しかし、質問の趣旨はそこではありません。なるようになる、ならないようになる。この質問は、純粋に実用的なもので、開発(おそらくあなたの場合も)にとって有益なものです。このような状況の処理、プログラマーの注文の不備をライブラリ自身が修正するというのはどういうことでしょうか? つまり、図書館自身がストップ高を逆転させたり、ロットを任意に変更したりするのですか? それとも、適切なコードを送信して、プロジェクターに間違った注文を知らせればいいのでしょうか? Dmitriy Parfenovich 2012.11.19 14:33 #69 papaklass:...プログラマーに注文が無効であることを伝え、エラーコードを 発行してから送信してはどうだろうか。 間違ったリクエストがクライアントの段階で切断され、サーバーに到達していないようです。 --- 2012.11.19 14:35 #70 papaklass: 答えは表面にある。なぜ、間違った注文をサーバーに送り、応答を待つのだろうか?なぜプログラマーにすぐに注文が間違っていることを伝え、エラーコードを 発行してから送らないのか?CTrade::OrderSendに OrderCheckを 追加するということでしょうか? 12345678 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
私の投稿は、なぜ標準ライブラリを 使わないのかという疑問に対する答えです
実は、私もそうなんです。でも、その理由は、私がMKよりずっと早くクラスを作ったからです。
と、クラス内のメタドの冗長性に開発者の注意を喚起する試みです。
ラッパーに対する考え方が違うだけで、クラス設計や取引構造のロジックも違いますから、好みの問題でしょう。
------------------------
例えば、10008 -> 10012のような普遍的な処理方法はあるのでしょうか?
例えば、Expert Advisorの前後の動作とは無関係に、です。
この注文の処理結果はどうなるのでしょうか?
未使用の関数は、最終的なファイルから除外されるようなものです。
もうひとつは、ほとんどの場合、「非ユニバーサル」コードの方がユニバーサルコードより速いという ことです(たとえばEAはより速く最適化され、クラウドの報酬は少し低くなります)。
コードの中で呼び出される関数だけを取り出し、それ以外は最適化の際にスキップされます。つまり、61個のメソッドを持つクラスのうち、3個だけ使用する場合、含まれるのは3個のメソッドのコードである。
インライン関数では、関数自体のサイズが小さいことと、コード全般の最適 化を考慮し、シンプルでフラットなコードを実現しています。
したがって、あるティックでポジションが開かれなければ、次のティックで開かれることになるので、この場合(10008→10012)には興味がないのです。
Expert Advisorのロジックでポジションを開く 必要がある場合は、ほとんどの場合、ポジションを開くようにコードを構築するよう心がけています。次のティックで開くか、10ティック後に開くか。
というのは、まさにその通りです。
そして、エラー処理の問題に戻りますが、標準ライブラリに欠けているものは何でしょうか?エラー処理/解析の方向で、どのような改良を加えたいのだろうか?
資金量以上のロットでポジションを建てる場合、または保留注文を出す場合、現在価格からの最小許容ステップを維持しない、またはポジションの方向を 考慮せずにストップを置く場合。
また、このような状況の処理、プログラマーの注文の不備をライブラリ自身が修正するというのはどういうことでしょうか。
つまり、図書館の判断で停車駅を逆転させたり、ロットを変更したりするのですか?
それとも、適切なコードを送信して、プロジェクターに間違った注文を知らせるのでしょうか?
といった状況を処理することで、プログラマーの注文の不備をライブラリ自身が修正するというのはどういうことなのでしょうか?
つまり、図書館が自らの判断で停車駅を逆転させたり、ロットを変更したりするように?
ただ、プログラマーによって「必要性と充足感」の認識が異なるため、機能拡張に対する疑問が生じるのです。
推測のままでいるより、完全にクリアにしたほうがいいのです。
もう一度言いますが、私は誰も納得させることができないのです。ビブリオでいいと思うんだから、そのままでいいじゃないですか。このような議論を経ても、私はこの図書館を利用しない。私一人でいいんですか?
アレクサンダーさん、あなただけではありません。しかし、質問の趣旨はそこではありません。なるようになる、ならないようになる。
この質問は、純粋に実用的なもので、開発(おそらくあなたの場合も)にとって有益なものです。
このような状況の処理、プログラマーの注文の不備をライブラリ自身が修正するというのはどういうことでしょうか?
それとも、適切なコードを送信して、プロジェクターに間違った注文を知らせればいいのでしょうか?つまり、図書館自身がストップ高を逆転させたり、ロットを任意に変更したりするのですか?
...プログラマーに注文が無効であることを伝え、エラーコードを 発行してから送信してはどうだろうか。
答えは表面にある。なぜ、間違った注文をサーバーに送り、応答を待つのだろうか?なぜプログラマーにすぐに注文が間違っていることを伝え、エラーコードを 発行してから送らないのか?