OOPと手続き型プログラミングの比較 - ページ 8 123456789101112131415...48 新しいコメント Vladimir Pastushak 2017.08.11 21:24 #71 Dmitry Fedoseev: すべてのオープンオーダーをすべてのパラメータとともに配列にロードするのは合理的なアプローチではないかもしれません。おそらく、私のコードで利益とストップロスの 2つのパラメータが必要な場合、ループを2回実行するのは高すぎます。これは世界共通のコードなので、不要なものを削って最終的なスピードを上げる......。 Реter Konow 2017.08.11 21:24 #72 Vladimir Pastushak: シンプリファイ だから私はOOPに耐えられないんです。何も理解することができないのです。解説がないんです。最後に求められるものは何でしょうか? Dmitry Fedoseev 2017.08.11 21:25 #73 Реter Konow: だから私はOOPに耐えられないんです。何も理解することができないのです。解説がないんです。最終的に何が求められるか?さっそく勉強してみたらどうだろう? Vladimir Pastushak 2017.08.11 21:27 #74 Реter Konow: だから、私はOOPが嫌いなんです。何も理解することができないのです。コメントはありません。最終的に何が求められるか?それが、わかっていないのに、すべての命令を配列構造で持っていて、どこでも簡単に呼び出せるということです。しかも、ヘビーループは1回しか実行しないし...。 Реter Konow 2017.08.11 21:27 #75 Dmitry Fedoseev: さっそく勉強してみたらどうだろう? ループ内で配列を 関数値で埋めます。問題は、なぜクラスシェルが必要なのか、ということです。機能でなんとかなる。 Vladimir Pastushak 2017.08.11 21:29 #76 Реter Konow: ループ内の関数の値で配列を埋めます。問題は、なぜクラスシェルが必要なのか、ということです。関数でできる。関数呼び出しが少なければ少ないほど、コードは高速になります。 Dmitry Fedoseev 2017.08.11 21:29 #77 Реter Konow: ループ内で配列に 関数の値を入れる。問題は、なぜクラスシェルが必要なのか、ということです。関数でも可能です。配列を積み上げたり、個別にサイズを変更したりする必要がなく、非常に便利な構造です。この例は、OOPの利点を示すものではなく、誰もが個人的に快適な方法でやっているというだけのことです。 Реter Konow 2017.08.11 21:29 #78 Vladimir Pastushak: それが、わかっていないのに、すべての命令を配列構造で持っていて、どこでも簡単に呼び出せるということです。同時に、重いループを一度だけ走らせる...。 理解できないのは、自分のコードじゃないし、一部に過ぎないからだと理解しています。でも、あなたも理解していないようですね。私が間違っているのでしょうか? СанСаныч Фоменко 2017.08.11 21:29 #79 Dmitry Fedoseev:紳士的な論客の皆さん、こう言いましょう、OOPを理解していない、知らない、ならば、手続き型プログラミング対OOPではなく、関数へのポインタを持つ手続き型プログラミング対関数へのポインタを持たない手続き型プログラミングで議論しましょうよ。いいえ、あなたの例はとても良いものです。手続き型プログラミングのことではありません。プログラムの品質には、コードの明確さというもっと重要な基準があります。あなたの出した解答はひどいものです。どのような関数が意味を持って呼び出されているのかがまったくわかりません。それぞれのコールに対して、通常のスイッチとコメントを書くのです。これが正しいコードです。あなたの例から、私はOOPは有害であると結論付けます。 Реter Konow 2017.08.11 21:31 #80 Vladimir Pastushak: 関数呼び出しが少なければ少ないほど、コードは高速になります。 だから、私は大きな汎用的なコードのブロックを作るのが好きなんです。 123456789101112131415...48 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
すべてのオープンオーダーをすべてのパラメータとともに配列にロードするのは合理的なアプローチではないかもしれません。
おそらく、私のコードで利益とストップロスの 2つのパラメータが必要な場合、ループを2回実行するのは高すぎます。
これは世界共通のコードなので、不要なものを削って最終的なスピードを上げる......。
シンプリファイ
だから私はOOPに耐えられないんです。何も理解することができないのです。解説がないんです。最終的に何が求められるか?
さっそく勉強してみたらどうだろう?
だから、私はOOPが嫌いなんです。何も理解することができないのです。コメントはありません。最終的に何が求められるか?
それが、わかっていないのに、すべての命令を配列構造で持っていて、どこでも簡単に呼び出せるということです。しかも、ヘビーループは1回しか実行しないし...。
さっそく勉強してみたらどうだろう?
ループ内の関数の値で配列を埋めます。問題は、なぜクラスシェルが必要なのか、ということです。関数でできる。
関数呼び出しが少なければ少ないほど、コードは高速になります。
ループ内で配列に 関数の値を入れる。問題は、なぜクラスシェルが必要なのか、ということです。関数でも可能です。
配列を積み上げたり、個別にサイズを変更したりする必要がなく、非常に便利な構造です。この例は、OOPの利点を示すものではなく、誰もが個人的に快適な方法でやっているというだけのことです。
それが、わかっていないのに、すべての命令を配列構造で持っていて、どこでも簡単に呼び出せるということです。同時に、重いループを一度だけ走らせる...。
紳士的な論客の皆さん、こう言いましょう、OOPを理解していない、知らない、ならば、手続き型プログラミング対OOPではなく、関数へのポインタを持つ手続き型プログラミング対関数へのポインタを持たない手続き型プログラミングで議論しましょうよ。
いいえ、あなたの例はとても良いものです。
手続き型プログラミングのことではありません。
プログラムの品質には、コードの明確さというもっと重要な基準があります。
あなたの出した解答はひどいものです。どのような関数が意味を持って呼び出されているのかがまったくわかりません。それぞれのコールに対して、通常のスイッチとコメントを書くのです。これが正しいコードです。
あなたの例から、私はOOPは有害であると結論付けます。
関数呼び出しが少なければ少ないほど、コードは高速になります。