Mt4 サポート終了。 - ページ 11 1...456789101112131415161718...47 新しいコメント Реter Konow 2017.09.10 07:30 #101 Vladimir:ユーザーとのインターフェイスを整理するためとか？そこで、OOPの多くのバリエーションが考案されたのが、Delphiのビジュアルコンポーネントライブラリです。 つまり、Expert Advisorやスクリプトは、コンピュータ上で人間の代わりになるように設計されており、このインターフェースはその目的に直接反している、必要ないものなのです。つまり、邪魔なのです。ペンナイフの不要品と同じです。また、万能ハンマーのスチール製ハンドルの先端に釘打ち機を取り付けると、傷がつくだけでなく、重心がストライカーからハンドルに移動してしまうのです。 この点については、私は反対です。完全に自動化されたEAは、半自動化されたものよりもはるかに効率が悪いことを理解しているアルゴトレーダーにとって、グラフィカルなインターフェイスは 必要かもしれません。自動売買と手動売買を組み合わせることで、取引の観点からより専門的で収益性の高い取引を行うことができます。それに気づいたとき、ロボットは必ずインターフェースを必要とする。 Dmitiry Ananiev 2017.09.10 10:03 #102 Реter Konow:1. graph_id は m_chart_id よりも早くロシア語圏の人に読まれる可能性がある。2.プログラム中に何百もの変数がある場合、Russianは不可欠なサポートを提供します。これらはすべて、実験で検証することができます。母国語のコードを読み、理解するスピードは常に速く、暗記力も高くなります。ロシア語で変数の命名のルールを理解すればいいのです。variable_to_store_general_profit_position」の代わりに、「general_profit」でいいんです。プログラム中に何百もの変数がある場合、そのほとんどは構造体によって結合することができるだろう。また、機能の活用も忘れてはいけません。 多くの変数は、カウンタであり、中間データの一時的な保存場所であり、たくさんの括弧の後ろで使われているため、全く意味を持ちません。そして何より、すべての括弧の後ろで、同じ変数を再び括弧{...}で囲んで使うことができるのです。あるいは最初はOOPで書く。 Georgiy Merts 2017.09.10 10:38 #103 Artyom Trishkin:彼がOOPを否定する本質は、ここにあるように思う。もちろん間違っているかもしれませんが、私は通常、人を感じるのです。私の考えでは、多くの非OBOの問題は、「法的権利を制限すること」に対する内的抵抗です。古いタイプのプログラマーは、どんなデータ、どんなブロック、どんなプログラムエンティティにも、いつでもフルアクセスできることに慣れている。そして、OOPアプローチとは逆に、データやプログラム動作のごく一部にしかアクセスできない場合、その権利を最大限に制限することを意味します。 私の記憶では、あまり好きではなかったのですが。Windowsの初期には、保護されたメモリアクセスに強い嫌悪感を覚えたものです。好きなアドレスにアクセスできないのだから、それがシステムカーネルにあったらどうするのか？プログラムから読み込ませるか、まったく変更しないでほしいですさらに、ダイレクトメモリアクセスコントローラをプログラムして、「禁止」された領域のデータを「許可」された領域に送り、システムの制限を回避することもしました。でも、時間が経つにつれて、これらの制約が本当にありがたく感じられるようになりました。"不要 "なアクセスは、必ずエラーになる。つまり、アクセス制御の作業をコンパイラに移すことは非常に賢明なことなのです。 ここでアクセスを制限する ことは、「権利の侵害」ではなく「フールプルーフ」であると判明しました。もし、ないアクセスが必要なら、それはシステムの設計を間違えたというだけです。必要なら、それを用意するべきだったのです。そして今は......逆に、いつもできるだけアクセスを制限しています。どんなときでも、必要なエンティティにしかアクセスできないようにする必要があります。それ以外のエンティティはアクセスできないようにする必要があります。これは、アクセスしてはいけない場所へのアクセスによるミスを防ぐとともに、すべての操作を一箇所で行い、他の場所には影響を与えないという、システム開発の一定の順序に慣れるためでもあるのです。 Georgiy Merts 2017.09.10 10:43 #104 Mickey Moose: 例えば、私はライブラリのような形のinludesが嫌いなんです。リ・タグ・コノウと同じようなものです。その理由は？ 1つの同じ関数が多くの場所で必要とされています。ライブラリにすべてを持たせることができるのに、なぜ関数をコピーするのでしょうか。そして、不要なブロックでメインコードを散らかさないのでしょうか。 Mickey Moose 2017.09.10 11:02 #105 George Merts:その理由は？ 1つの同じ関数が多くの場所で必要とされる。すべてをライブラリに格納すれば、不要なブロックでメインコードを散らかさずに済むのに、なぜ関数をコピーするのだろう？ この場合の機能は、自分で小さなデータベースを作っておいて、必要な時に入手・追加しています。1MBのDLLを逆コンパイルして、中身を読んで理解することがどういうことか想像してみてください。なぜそんなに余計なことをするのか？ Artyom Trishkin 2017.09.10 11:09 #106 Реter Konow:論点を見つけるのがうまいですね、ニコライさん）。おばあちゃんも、何事も問題なく吸収できる。ただ、彼女は無意識のうちに、落ち着いた心を不要な情報のサイクルに引きずり込むような小細工をしたくないのだ。正にその通り）。ピーターさん、おばあちゃんなんですね。 Targ 2017.09.10 11:11 #107 こんにちはここでなら助けてもらえるかもしれない。MT4の開発者の方に質問です。どこで声を出せるか。このフォーラムでなら、どのスレッドで？それとも別の場所？知っている人は教えてください。 Artyom Trishkin 2017.09.10 11:13 #108 Реter Konow:この点については、私は反対です。完全に自動化されたEAは、半自動化されたものよりもはるかに効率が悪いことを認識しているアルゴトレーダーにとって、グラフィカルなインターフェイスは必要かもしれません。自動売買と手動売買を組み合わせることで、取引の観点からより専門的で収益性の高い取引を行うことができます。それに気づいたとき、ロボットは必ずインターフェースを必要とする。mqlはサーバーアクセス機能だけでよくて、それ以外の松葉杖によるものはサードパーティの開発ツールでプログラムすればいいという人を全面的に支持するんですね。党の方針から逸脱しないように。一貫性を保つ - mqlに開発したものをすべて捨て、ブリッジを作る - 例えばスタジオに - あるいはキャンバスを書く場所に......。そして、次に工場に勝利したことを報告する。 Artyom Trishkin 2017.09.10 11:15 #109 Mickey Moose: 例えば、私はライブラリのような形のinludesが嫌いなんです。レトログ・コノウのものと同様です。さて、エネルギー保存の法則ですが、ライブラリがなくてもすべてが動くのであれば、なぜライブラリを逆コンパイルして理解する必要があるのでしょうか？追伸ヘラジカについての私のトップページはご覧になりましたか？コードが10、20、30、...と溢れ出したら。10万行のコードをどうやってコピーしたのか、教えてください。 Реter Konow 2017.09.10 11:16 #110 George Merts:私の考えでは、多くの非OBOの問題は、「法的権利を制限すること」に対する内的抵抗です。古いタイプのプログラマーは、どんなデータ、どんなブロック、どんなプログラムエンティティにも、いつでもフルアクセスできることに慣れている。そして、OOPアプローチとは逆に、データやプログラム動作のごく一部にしかアクセスできない場合、その権利を最大限に制限することを意味します。 私の記憶では、あまり好きではなかったのですが。Windowsの初期には、保護されたメモリアクセスに強い嫌悪感を覚えたものです。好きなアドレスにアクセスできないのだから、それがシステムカーネルにあったらどうするのか？プログラムから読みたいとか、全然変えたいとか、そういうのだってあるんですさらに、システムの制限をかいくぐって、「禁止領域」から「許可領域」にデータを送るダイレクトメモリアクセスコントローラーをプログラムしたこともありました。でも、時間が経つにつれて、これらの制約が本当にありがたく感じられるようになりました。"不要 "なアクセスは、必ずエラーになる。つまり、アクセス制御の作業をコンパイラに移すことは非常に賢明なことなのです。 ここでアクセスを制限する ことは、「権利の侵害」ではなく「フールプルーフ」であると判明しました。もし、ないアクセスが必要なら、それはシステムの設計を間違えたというだけです。必要なら、それを用意するべきだったのです。そして今は......逆に、いつもできるだけアクセスを制限しています。どの時点でも、アクセスする必要のあるエンティティのみが利用可能であるべきです。それ以外のオブジェクトはアクセスできないようにしなければならない。これは、アクセスしてはいけない場所へのアクセスによるミスを防ぐとともに、すべての操作を一箇所で行い、他の場所には影響を与えないという、システム開発の一定の順序に慣れるためでもあるのです。OOPが何をはじき出すか、いい例をあげてくれましたね。 私の場合は、少し違っていました。しかし、あるときからOOPを使うことに何のメリットも感じられなくなりました。今でもそれは変わっていません。すべては、私がOOPを実践から押し出したアプローチを形成したためです。この「アクセス制限は、エラーを防ぐために必要な保護機能である」という言葉は、私にはまったく理解できない。プログラムの異なる部分で変数名が一致する場合は、もちろんイエスです。しかし、1つの配列にすべての主要なグローバル変数の共通のグローバルメモリがあれば、制限は必要なく、混乱も起こりません。 1...456789101112131415161718...47 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
Vladimir:
ユーザーとのインターフェイスを整理するためとか？そこで、OOPの多くのバリエーションが考案されたのが、Delphiのビジュアルコンポーネントライブラリです。 つまり、Expert Advisorやスクリプトは、コンピュータ上で人間の代わりになるように設計されており、このインターフェースはその目的に直接反している、必要ないものなのです。つまり、邪魔なのです。ペンナイフの不要品と同じです。また、万能ハンマーのスチール製ハンドルの先端に釘打ち機を取り付けると、傷がつくだけでなく、重心がストライカーからハンドルに移動してしまうのです。
この点については、私は反対です。
完全に自動化されたEAは、半自動化されたものよりもはるかに効率が悪いことを理解しているアルゴトレーダーにとって、グラフィカルなインターフェイスは 必要かもしれません。自動売買と手動売買を組み合わせることで、取引の観点からより専門的で収益性の高い取引を行うことができます。それに気づいたとき、ロボットは必ずインターフェースを必要とする。
1. graph_id は m_chart_id よりも早くロシア語圏の人に読まれる可能性がある。
2.プログラム中に何百もの変数がある場合、Russianは不可欠なサポートを提供します。
これらはすべて、実験で検証することができます。
母国語のコードを読み、理解するスピードは常に速く、暗記力も高くなります。
ロシア語で変数の命名のルールを理解すればいいのです。variable_to_store_general_profit_position」の代わりに、「general_profit」でいいんです。
プログラム中に何百もの変数がある場合、そのほとんどは構造体によって結合することができるだろう。また、機能の活用も忘れてはいけません。
多くの変数は、カウンタであり、中間データの一時的な保存場所であり、たくさんの括弧の後ろで使われているため、全く意味を持ちません。そして何より、すべての括弧の後ろで、同じ変数を再び括弧{...}で囲んで使うことができるのです。
あるいは最初はOOPで書く。
彼がOOPを否定する本質は、ここにあるように思う。もちろん間違っているかもしれませんが、私は通常、人を感じるのです。
私の考えでは、多くの非OBOの問題は、「法的権利を制限すること」に対する内的抵抗です。
古いタイプのプログラマーは、どんなデータ、どんなブロック、どんなプログラムエンティティにも、いつでもフルアクセスできることに慣れている。そして、OOPアプローチとは逆に、データやプログラム動作のごく一部にしかアクセスできない場合、その権利を最大限に制限することを意味します。
私の記憶では、あまり好きではなかったのですが。Windowsの初期には、保護されたメモリアクセスに強い嫌悪感を覚えたものです。好きなアドレスにアクセスできないのだから、それがシステムカーネルにあったらどうするのか？プログラムから読み込ませるか、まったく変更しないでほしいですさらに、ダイレクトメモリアクセスコントローラをプログラムして、「禁止」された領域のデータを「許可」された領域に送り、システムの制限を回避することもしました。
でも、時間が経つにつれて、これらの制約が本当にありがたく感じられるようになりました。"不要 "なアクセスは、必ずエラーになる。つまり、アクセス制御の作業をコンパイラに移すことは非常に賢明なことなのです。 ここでアクセスを制限する ことは、「権利の侵害」ではなく「フールプルーフ」であると判明しました。もし、ないアクセスが必要なら、それはシステムの設計を間違えたというだけです。必要なら、それを用意するべきだったのです。
そして今は......逆に、いつもできるだけアクセスを制限しています。どんなときでも、必要なエンティティにしかアクセスできないようにする必要があります。それ以外のエンティティはアクセスできないようにする必要があります。これは、アクセスしてはいけない場所へのアクセスによるミスを防ぐとともに、すべての操作を一箇所で行い、他の場所には影響を与えないという、システム開発の一定の順序に慣れるためでもあるのです。
例えば、私はライブラリのような形のinludesが嫌いなんです。
リ・タグ・コノウと同じようなものです。
その理由は？
1つの同じ関数が多くの場所で必要とされています。ライブラリにすべてを持たせることができるのに、なぜ関数をコピーするのでしょうか。そして、不要なブロックでメインコードを散らかさないのでしょうか。
その理由は？
1つの同じ関数が多くの場所で必要とされる。すべてをライブラリに格納すれば、不要なブロックでメインコードを散らかさずに済むのに、なぜ関数をコピーするのだろう？
論点を見つけるのがうまいですね、ニコライさん）。
おばあちゃんも、何事も問題なく吸収できる。ただ、彼女は無意識のうちに、落ち着いた心を不要な情報のサイクルに引きずり込むような小細工をしたくないのだ。正にその通り）。
ピーターさん、おばあちゃんなんですね。
こんにちは
ここでなら助けてもらえるかもしれない。MT4の開発者の方に質問です。どこで声を出せるか。このフォーラムでなら、どのスレッドで？それとも別の場所？知っている人は教えてください。
この点については、私は反対です。
完全に自動化されたEAは、半自動化されたものよりもはるかに効率が悪いことを認識しているアルゴトレーダーにとって、グラフィカルなインターフェイスは必要かもしれません。自動売買と手動売買を組み合わせることで、取引の観点からより専門的で収益性の高い取引を行うことができます。それに気づいたとき、ロボットは必ずインターフェースを必要とする。
mqlはサーバーアクセス機能だけでよくて、それ以外の松葉杖によるものはサードパーティの開発ツールでプログラムすればいいという人を全面的に支持するんですね。党の方針から逸脱しないように。一貫性を保つ - mqlに開発したものをすべて捨て、ブリッジを作る - 例えばスタジオに - あるいはキャンバスを書く場所に......。そして、次に工場に勝利したことを報告する。
例えば、私はライブラリのような形のinludesが嫌いなんです。
レトログ・コノウのものと同様です。
さて、エネルギー保存の法則ですが、ライブラリがなくてもすべてが動くのであれば、なぜライブラリを逆コンパイルして理解する必要があるのでしょうか？
追伸
ヘラジカについての私のトップページはご覧になりましたか？
コードが10、20、30、...と溢れ出したら。10万行のコードをどうやってコピーしたのか、教えてください。
私の考えでは、多くの非OBOの問題は、「法的権利を制限すること」に対する内的抵抗です。
古いタイプのプログラマーは、どんなデータ、どんなブロック、どんなプログラムエンティティにも、いつでもフルアクセスできることに慣れている。そして、OOPアプローチとは逆に、データやプログラム動作のごく一部にしかアクセスできない場合、その権利を最大限に制限することを意味します。
私の記憶では、あまり好きではなかったのですが。Windowsの初期には、保護されたメモリアクセスに強い嫌悪感を覚えたものです。好きなアドレスにアクセスできないのだから、それがシステムカーネルにあったらどうするのか？プログラムから読みたいとか、全然変えたいとか、そういうのだってあるんですさらに、システムの制限をかいくぐって、「禁止領域」から「許可領域」にデータを送るダイレクトメモリアクセスコントローラーをプログラムしたこともありました。
でも、時間が経つにつれて、これらの制約が本当にありがたく感じられるようになりました。"不要 "なアクセスは、必ずエラーになる。つまり、アクセス制御の作業をコンパイラに移すことは非常に賢明なことなのです。 ここでアクセスを制限する ことは、「権利の侵害」ではなく「フールプルーフ」であると判明しました。もし、ないアクセスが必要なら、それはシステムの設計を間違えたというだけです。必要なら、それを用意するべきだったのです。
そして今は......逆に、いつもできるだけアクセスを制限しています。どの時点でも、アクセスする必要のあるエンティティのみが利用可能であるべきです。それ以外のオブジェクトはアクセスできないようにしなければならない。これは、アクセスしてはいけない場所へのアクセスによるミスを防ぐとともに、すべての操作を一箇所で行い、他の場所には影響を与えないという、システム開発の一定の順序に慣れるためでもあるのです。
OOPが何をはじき出すか、いい例をあげてくれましたね。
私の場合は、少し違っていました。しかし、あるときからOOPを使うことに何のメリットも感じられなくなりました。今でもそれは変わっていません。すべては、私がOOPを実践から押し出したアプローチを形成したためです。
この「アクセス制限は、エラーを防ぐために必要な保護機能である」という言葉は、私にはまったく理解できない。プログラムの異なる部分で変数名が一致する場合は、もちろんイエスです。しかし、1つの配列にすべての主要なグローバル変数の共通のグローバルメモリがあれば、制限は必要なく、混乱も起こりません。