Mt4 サポート終了。 - ページ 28 1...212223242526272829303132333435...47 新しいコメント Aleksey Altukhov 2017.09.11 05:08 #271 誰かが提案したのかわかりませんが、MT4のすべてをMT5に移行したらどうでしょう、そうすればみんな移行するのではないでしょうか。 Andrei01 2017.09.11 05:15 #272 George Merts:まずパーツを書いてから、それを組み合わせて全体を作るのだが、パーツ同士の相性が悪いことがよくある。ちなみに、「利用可能なすべての変数にアクセスできるようにしたい」というのは、このことからきているのだ。いいえ、そんなことはありません。すべての変数にアクセスできるのではなく、必要な変数だけにアクセスできることが重要なのです。これらは通常、異なる関数の入力変数と出力変数である。 ここに境界線を追加すると、コードの可読性が 大幅に低下し、境界線のために途中で何かを見失い、そこに到達できなかった場合のエラーも増加する可能性があります。 確かに、少なくとも何とかしてOOPを有用なものに引き戻したいという願望は理解できますが、そのようなケースは通常、プログラミングの分野ではなく、例えば余分なプログラミング時間、インターフェイスのアーキテクチャに関する無限の議論の作成と作業時間の楽しい娯楽のための商業球にあるのです。 Andrei01 2017.09.11 05:26 #273 Vladimir:原則的に、そのような例は あるのでしょうか？自分のものでなくとも？深い疑問があります。2000年代の初め、私は自分で書いたプログラムコードのデバッグと動作の行数が100万行を超えたので数えるのをやめた。また、仕事の種類や規模は多岐にわたりますが、自分で授業を作る必要性に遭遇したことはありません。数人分の作業を並列化する必要があるときはプロシージャ型の変数を使うこともありましたが、それ以上はないですね。なぜそうなのでしょうか。 要は、OOPは出来上がったコードのパッケージングにしか適用できず、コードを書く段階でそれを防いでいるだけなのです。しかし、そのようなニーズがないのであれば、OOPも必要ないでしょう。ウラジミールOOPが計算の自動並列化を妨げていることが判明したのです。今となっては非常に重大な欠点と考えるべきで、視点はOOP向きではありません。視点はSystemverilogのような言語にあります。 Georgiy Merts 2017.09.11 05:32 #274 Dmitry Fedoseev:isNewBar()関数が全く存在しないはずであることを除けば、問題ないでしょう。こんな些細なことでこんなに踊らされるなんておかしいよ。これは単なる変数で、単純にバーの時間と比較されます。すべてのケースが成功した場合、この変数には最後に新しいバーの 時間が代入されます。そうでない場合は、すべてのケースに1回だけ試行が割り当てられます。 これは、まさに私がやってきたことです。 Georgiy Merts 2017.09.11 05:40 #275 Andrei:ここに境界線を追加すると、コードの可読性は 一気に低下し、境界線のために何かが途中で迷子になり、どこかにたどり着けなかったというエラーの可能性が高まります。 その逆で、境界線があることで「なぜこの変数なのか、この場合どんな役割を果たすのか、考慮すべきなのか」ということを考えずにすむのです。 ユーザーは、検討する必要があるものだけにアクセスし、変更できるものだけにアクセスすることができます。これらはまさに「途中で何かが失われたとき」のエラーであり、多すぎるがゆえに「途中で何かが忘れられたとき」に発生するものである。切り捨てられた」バーチャル・インタレストの場合、これはかなり困難です。ここでは最も単純な例として、ポジションを獲得することを挙げています。ポジションとは、MT4では未決済の注文、MT5では未決済のポジションのことです。もしフルアクセスであれば、ポジションを選択する際に、どの変数が今読み取れて、どの変数が今無効で、どの変数が変更できて、どれができないかをユーザーが覚えておかなければならないのです。インターフェースでは、よりシンプルになりました。手に入れたのは、成分数の取得と、定数成分へのポインタの取得の2つの関数だけだ。以上です。この2つの関数では、物理的に「余分な変数」にアクセスすることはできません。アンドレイもちろん、せめて何か便利なことにOOPを利用したいという気持ちはわかりますが、そのようなケースは通常、プログラミングの分野ではなく、余分なプログラミング時間、インターフェイスのアーキテクチャに関する果てしない議論など、オフィスアワーの楽しい娯楽といった商業領域にあるのです。そして、遅かれ早かれ、このことに気がつくでしょう。さらに、カプセル化は「純粋に手続き的」なアプローチで行うことができます。しかし、OOPアプローチでは、やはり「自動的に」継承やポリモーフィズムが得られるので、より便利です。 Andrew Petras 2017.09.11 05:41 #276 Aleksey Altukhov:誰かが提案したのかわかりませんが、MT4のすべてをMT5に移行したらどうでしょう、そうすればみんな移行するのではないでしょうか。問題は、4にはあって5にはないものがあるということだけではありません。しかも、OOPでもない。5は、トレーダー（プログラマーやソフトウェアトレーダーではなく、単なるトレーダー）に対して実質的に何も与えていないのです。自作履歴のフォーマット、カスタムの禁止、しかしこの2点がジオメトリを取引する人たちを怖がらせてしまった。そして、「多くのTF」（年号がない、笑）、バーごとのpipsでのスキャルは、それらを引き寄せることができません。素朴な疑問です。グリッド」は何を示しているのでしょうか？調べようとすると、フリーランスになって好きなものを注文することを勧めることになる。MTはプログラマーのための端末です。それが答えの全てです。 Georgiy Merts 2017.09.11 05:45 #277 Andrei:問題は、OOPが適用できるのは準備の整ったコードの梱包時だけで、コードを書く段階では邪魔になるだけだということです。しかし、そのような必然性がないのであれば、OOPには必要ない。いいえ、そんなことはありません。ちょうどその逆ですね。インターフェイスは、「コードを書く前の段階」でも最初に定義される。 インターフェイスは、実は、プログラマーにとって、すべて同じToRなのだ。Freelanceにおけるすべてのインタラクションは、明示的なToRを使用して実行されます。つまり、仮想インターフェイスは一種のTORであり、そこからプログラミングが始まるわけです。 ただ、私の理解では、あなたはOOPの本質に間違って アプローチしているように思います。まず関数をたくさん書いて、それをOOP設計で「絞る」んです。しかし、これは間違った方法です。正しい方法はその逆で、まずOOP定義、つまりシステムの構成要素間の基本的なインターフェースのセットを定義することです。そして、その定義されたインターフェースに従って、一つひとつの部品を書いていきます。 そうそう、コードを書いているときに、インターフェースで用意されていないものがあることに気づくことがある。そして、あなたが始めるのは..."ああ...手続き的なアプローチでは、すべての変数にアクセスできて、必要なことをするのに問題はなかったのですが、今は、これらの変数にどうやってアクセスすればいいのでしょうか？これは、インターフェイスの設計段階で、何かが考慮されていなかった場合に起こります。これは非常に不愉快な状況です。インターフェースを追加するか、既存のものを変更しなければなりませんが、これはエラーに満ちています。このような事態はもちろん避けなければならない。 Andrei01 2017.09.11 05:47 #278 George Merts:ここでは最も単純な例として、ポジションを得るということを挙げています。ポジションとは、MT4では未決済の注文、MT5では未決済のポジションのことです。フルアクセスが可能な場合、ポジションを選択する際に、ユーザーはどの変数が今読み取れて、どの変数が現在無効で、どの変数が変更可能で、どの変数が不可能かを覚えておく必要があります。インターフェースでは、よりシンプルになりました。手に入れたのは、成分数の取得と、定数成分へのポインタの取得の2つの関数だけだ。以上です。この2つの関数では、物理的に「余分な変数」にアクセスすることはできません。 ちょうどその逆です。ユーザーは、例えばモジュールの品質テストのために内部変数を知る必要がある場合が多いのです。そして、このアクセスを得るために、後から特別な巧妙な方法が考案される。ですから、原則的に不要な情報はありませんし、不要な人は使わなければいいだけです。 Georgiy Merts 2017.09.11 05:58 #279 Andrei:これは全く逆です。ユーザーは、例えば品質モジュールをテストするために、内部変数を知る必要がある場合が多いのです。そして、このアクセスを得るために、後から特別に巧妙な方法を考え出すのです。だから、無駄な情報はなく、必要ない人は使わなければいいのです。もし、"巧妙なアクセス "が必要なら、それは間違ったシステム設計 であることを意味します。 例えば、入力信号のジェネレーターを作成する場合、資金管理に関する情報にはアクセスできないようにする必要があります。 もちろん、デバッグ中に「エントリーがない」という事態が発生することもある。資金運用が禁止されている（マージンが足りないなど）ために発生した事態は、すぐに排除する必要がある。また、エントリージェネレーターからどうやって知ることができるのですか？あなたは、アクセスできないのです。しかし、この場合は、ジェネレーターがエントリーのための信号を設定し、それが正しく動作したことを確認するだけで十分です。入力がない - 入力ジェネレーターの外にある、何か他の理由によるものだ。この場合、資金運用のすべての変数に直接アクセスできる場合よりも、その理由を見つけるのは実に難しい。しかし、通常のルーティンワークでは、アクセスする私たちが「間違った場所に入り込んでしまう」ことの方が、はるかに危険なのです。 Реter Konow 2017.09.11 06:39 #280 George Merts:もし、「トリッキーなアクセス方法」が必要な場合は、システム設計が不十分であることを示しています。 開発とは、まず第一に、心の自然なプロセスである。 この過程で、アイデアは自由に、しかも自発的に形成される。 OOPに従うと、コードを自由に変形させることが難しくなります。開発の自然なプロセスの中で、コード自体が徐々に縮小され、普遍化されていくのです。 自然のプロセスでは、機能はバラバラになるのではなく、逆に成長し、大きなブロックにまとまっていくのです。大きなブロックは、さまざまな課題を解決します。 OOPではこのようなブロックが形成されず、コードが断片化されたままになっています。OOPは複雑なアクセスを生み出し、変数への参照回数を着実に増やしていく。粒状性のメリットは、首尾一貫したメカニズムを作ることの難しさに負けるのです。主な欠点：OOPでは、コードをいくつかの関数に分割する方法に従わざるを得ない。人間は断片化されたコードを受け入れやすいですが、断片化はどんな仕組みにも禁忌です。 1...212223242526272829303132333435...47 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
誰かが提案したのかわかりませんが、MT4のすべてをMT5に移行したらどうでしょう、そうすればみんな移行するのではないでしょうか。
George Merts:
まずパーツを書いてから、それを組み合わせて全体を作るのだが、パーツ同士の相性が悪いことがよくある。ちなみに、「利用可能なすべての変数にアクセスできるようにしたい」というのは、このことからきているのだ。
いいえ、そんなことはありません。すべての変数にアクセスできるのではなく、必要な変数だけにアクセスできることが重要なのです。これらは通常、異なる関数の入力変数と出力変数である。
ここに境界線を追加すると、コードの可読性が 大幅に低下し、境界線のために途中で何かを見失い、そこに到達できなかった場合のエラーも増加する可能性があります。
確かに、少なくとも何とかしてOOPを有用なものに引き戻したいという願望は理解できますが、そのようなケースは通常、プログラミングの分野ではなく、例えば余分なプログラミング時間、インターフェイスのアーキテクチャに関する無限の議論の作成と作業時間の楽しい娯楽のための商業球にあるのです。
原則的に、そのような例は あるのでしょうか？自分のものでなくとも？深い疑問があります。2000年代の初め、私は自分で書いたプログラムコードのデバッグと動作の行数が100万行を超えたので数えるのをやめた。また、仕事の種類や規模は多岐にわたりますが、自分で授業を作る必要性に遭遇したことはありません。数人分の作業を並列化する必要があるときはプロシージャ型の変数を使うこともありましたが、それ以上はないですね。なぜそうなのでしょうか。
要は、OOPは出来上がったコードのパッケージングにしか適用できず、コードを書く段階でそれを防いでいるだけなのです。しかし、そのようなニーズがないのであれば、OOPも必要ないでしょう。
ウラジミール
OOPが計算の自動並列化を妨げていることが判明したのです。今となっては非常に重大な欠点と考えるべきで、視点はOOP向きではありません。
視点はSystemverilogのような言語にあります。
isNewBar()関数が全く存在しないはずであることを除けば、問題ないでしょう。こんな些細なことでこんなに踊らされるなんておかしいよ。
これは単なる変数で、単純にバーの時間と比較されます。すべてのケースが成功した場合、この変数には最後に新しいバーの 時間が代入されます。そうでない場合は、すべてのケースに1回だけ試行が割り当てられます。
ここに境界線を追加すると、コードの可読性は 一気に低下し、境界線のために何かが途中で迷子になり、どこかにたどり着けなかったというエラーの可能性が高まります。
その逆で、境界線があることで「なぜこの変数なのか、この場合どんな役割を果たすのか、考慮すべきなのか」ということを考えずにすむのです。
ユーザーは、検討する必要があるものだけにアクセスし、変更できるものだけにアクセスすることができます。これらはまさに「途中で何かが失われたとき」のエラーであり、多すぎるがゆえに「途中で何かが忘れられたとき」に発生するものである。切り捨てられた」バーチャル・インタレストの場合、これはかなり困難です。
ここでは最も単純な例として、ポジションを獲得することを挙げています。ポジションとは、MT4では未決済の注文、MT5では未決済のポジションのことです。
もしフルアクセスであれば、ポジションを選択する際に、どの変数が今読み取れて、どの変数が今無効で、どの変数が変更できて、どれができないかをユーザーが覚えておかなければならないのです。
インターフェースでは、よりシンプルになりました。手に入れたのは、成分数の取得と、定数成分へのポインタの取得の2つの関数だけだ。以上です。この2つの関数では、物理的に「余分な変数」にアクセスすることはできません。
アンドレイ
もちろん、せめて何か便利なことにOOPを利用したいという気持ちはわかりますが、そのようなケースは通常、プログラミングの分野ではなく、余分なプログラミング時間、インターフェイスのアーキテクチャに関する果てしない議論など、オフィスアワーの楽しい娯楽といった商業領域にあるのです。
そして、遅かれ早かれ、このことに気がつくでしょう。さらに、カプセル化は「純粋に手続き的」なアプローチで行うことができます。しかし、OOPアプローチでは、やはり「自動的に」継承やポリモーフィズムが得られるので、より便利です。
誰かが提案したのかわかりませんが、MT4のすべてをMT5に移行したらどうでしょう、そうすればみんな移行するのではないでしょうか。
問題は、4にはあって5にはないものがあるということだけではありません。しかも、OOPでもない。
5は、トレーダー（プログラマーやソフトウェアトレーダーではなく、単なるトレーダー）に対して実質的に何も与えていないのです。
自作履歴のフォーマット、カスタムの禁止、しかしこの2点がジオメトリを取引する人たちを怖がらせてしまった。そして、「多くのTF」（年号がない、笑）、バーごとのpipsでのスキャルは、それらを引き寄せることができません。
素朴な疑問です。グリッド」は何を示しているのでしょうか？調べようとすると、フリーランスになって好きなものを注文することを勧めることになる。
MTはプログラマーのための端末です。それが答えの全てです。
問題は、OOPが適用できるのは準備の整ったコードの梱包時だけで、コードを書く段階では邪魔になるだけだということです。しかし、そのような必然性がないのであれば、OOPには必要ない。
いいえ、そんなことはありません。ちょうどその逆ですね。
インターフェイスは、「コードを書く前の段階」でも最初に定義される。 インターフェイスは、実は、プログラマーにとって、すべて同じToRなのだ。Freelanceにおけるすべてのインタラクションは、明示的なToRを使用して実行されます。つまり、仮想インターフェイスは一種のTORであり、そこからプログラミングが始まるわけです。
ただ、私の理解では、あなたはOOPの本質に間違って アプローチしているように思います。まず関数をたくさん書いて、それをOOP設計で「絞る」んです。しかし、これは間違った方法です。正しい方法はその逆で、まずOOP定義、つまりシステムの構成要素間の基本的なインターフェースのセットを定義することです。そして、その定義されたインターフェースに従って、一つひとつの部品を書いていきます。
そうそう、コードを書いているときに、インターフェースで用意されていないものがあることに気づくことがある。そして、あなたが始めるのは..."ああ...手続き的なアプローチでは、すべての変数にアクセスできて、必要なことをするのに問題はなかったのですが、今は、これらの変数にどうやってアクセスすればいいのでしょうか？これは、インターフェイスの設計段階で、何かが考慮されていなかった場合に起こります。これは非常に不愉快な状況です。インターフェースを追加するか、既存のものを変更しなければなりませんが、これはエラーに満ちています。このような事態はもちろん避けなければならない。
ここでは最も単純な例として、ポジションを得るということを挙げています。ポジションとは、MT4では未決済の注文、MT5では未決済のポジションのことです。
フルアクセスが可能な場合、ポジションを選択する際に、ユーザーはどの変数が今読み取れて、どの変数が現在無効で、どの変数が変更可能で、どの変数が不可能かを覚えておく必要があります。
インターフェースでは、よりシンプルになりました。手に入れたのは、成分数の取得と、定数成分へのポインタの取得の2つの関数だけだ。以上です。この2つの関数では、物理的に「余分な変数」にアクセスすることはできません。
ちょうどその逆です。ユーザーは、例えばモジュールの品質テストのために内部変数を知る必要がある場合が多いのです。そして、このアクセスを得るために、後から特別な巧妙な方法が考案される。ですから、原則的に不要な情報はありませんし、不要な人は使わなければいいだけです。
これは全く逆です。ユーザーは、例えば品質モジュールをテストするために、内部変数を知る必要がある場合が多いのです。そして、このアクセスを得るために、後から特別に巧妙な方法を考え出すのです。だから、無駄な情報はなく、必要ない人は使わなければいいのです。
もし、"巧妙なアクセス "が必要なら、それは間違ったシステム設計 であることを意味します。
例えば、入力信号のジェネレーターを作成する場合、資金管理に関する情報にはアクセスできないようにする必要があります。
もちろん、デバッグ中に「エントリーがない」という事態が発生することもある。資金運用が禁止されている（マージンが足りないなど）ために発生した事態は、すぐに排除する必要がある。また、エントリージェネレーターからどうやって知ることができるのですか？あなたは、アクセスできないのです。しかし、この場合は、ジェネレーターがエントリーのための信号を設定し、それが正しく動作したことを確認するだけで十分です。入力がない - 入力ジェネレーターの外にある、何か他の理由によるものだ。この場合、資金運用のすべての変数に直接アクセスできる場合よりも、その理由を見つけるのは実に難しい。しかし、通常のルーティンワークでは、アクセスする私たちが「間違った場所に入り込んでしまう」ことの方が、はるかに危険なのです。
もし、「トリッキーなアクセス方法」が必要な場合は、システム設計が不十分であることを示しています。
開発とは、まず第一に、心の自然なプロセスである。
この過程で、アイデアは自由に、しかも自発的に形成される。
OOPに従うと、コードを自由に変形させることが難しくなります。
開発の自然なプロセスの中で、コード自体が徐々に縮小され、普遍化されていくのです。
自然のプロセスでは、機能はバラバラになるのではなく、逆に成長し、大きなブロックにまとまっていくのです。
大きなブロックは、さまざまな課題を解決します。
OOPではこのようなブロックが形成されず、コードが断片化されたままになっています。
OOPは複雑なアクセスを生み出し、変数への参照回数を着実に増やしていく。
粒状性のメリットは、首尾一貫したメカニズムを作ることの難しさに負けるのです。
主な欠点：OOPでは、コードをいくつかの関数に分割する方法に従わざるを得ない。
人間は断片化されたコードを受け入れやすいですが、断片化はどんな仕組みにも禁忌です。