OOPと手続き型プログラミングの比較 - ページ 38 1...313233343536373839404142434445...48 新しいコメント Maxim Kuznetsov 2017.08.15 20:44 #371 СанСаныч Фоменко: 私のOnInit()もほぼ同じで、十数行 です...それで？ これがプログラムの全てです。） Реter Konow 2017.08.15 20:45 #372 СанСаныч Фоменко: すげえええええええええええええええええええええええ現代のプログラミングにおいて、カーネルのレベルで問題を混乱させる方法は他にあるのでしょうか？ OOPは、機構の一部を分離し、包み込み、隠すための手法である。それが必要かどうかは、開発者の判断に委ねられます。機構の効率化とは全く関係ない。考え方の構造化ですね。正しく構成されているかは不明です。必要かどうかは、人それぞれです。 СанСаныч Фоменко 2017.08.15 20:56 #373 Maxim Kuznetsov: これがプログラム全体であるということは...他には何もないですね :-)もちろん、そんなことはありません。灰＋Rで他全部（彼はカウントされない）は、グローバル変数 です。グローバル変数（複数の関数の変数）にローカル変数が含まれないようにしています。やくすデバッグとは、2つのマスタの交点はあるが、信号はない、という論理のデバッグである。端末からの変数値把握に問題がある。ここで重要なのは、口座の種類を変えないこと、そしてできればブローカーを変えないことです。ここで上に書かれてるような情熱は知らんけど。 Maxim Kuznetsov 2017.08.15 21:00 #374 СанСаныч Фоменко: もちろん、そんなことはありません。灰＋Rで他全部（彼はカウントされない）は、グローバル変数 です。グローバル変数（複数の関数の変数）にローカル変数が含まれないようにしています。やくすデバッグは、2つのマッシュの交点があるのに信号がないという、ロジックのデバッグが重要なのです。端末からの変数値把握に問題がある。ここで重要なのは、口座の種類を変えないこと、そしてできればブローカーを変えないことです。上記のような情熱は一切意識していません。ただぶっちゃけ、リアルアカウントは全くないのでしょうか？ 情熱はリアルとの出会いと搾取・保守のあざとさからきているだけで、テスターにとっては何をどう書いてもいいわけで......。 СанСаныч Фоменко 2017.08.15 21:03 #375 Реter Konow: OOPは、機構の一部を分離し、包み込み、隠すための手法である。これが必要かどうかは、開発者の判断に委ねられます。機構の効率化とは全く関係ない。考え方の構造化ですね。正しく構成されているかは不明です。必要かどうかは、人それぞれです。関数を書くときに必ず問題になるのが1. 関数を作成する2. 別の関数を書いてみて、非常に似ているが最初の関数とは違うことがわかる。1つにまとめるべきか、2つに残すべきか、常にジレンマがあります。より多機能になったが、より複雑なコードを得ることができる。シンプルなコードなのに、たくさんの機能を手に入れることができます。このOOPはそういうものなんです。うまく構成された明確なクラスを少数だけ割り当てることができれば。Expert Advisorをたくさん 書くなら何らかの理由で修正することが多い場合次にOOPは便利です。そうでないなら、トレードとは関係ない情報で頭をいっぱいにする必要はなく、Rに時間を 費やした方が良いのではないでしょうか。皆さんも頑張ってください。 СанСаныч Фоменко 2017.08.15 21:07 #376 Maxim Kuznetsov:ただ、率直に言って - 少なくとも1つの本当のアカウント？ 情熱は、現実世界との衝突と運用/保守のあざからくるもので、テスターにとっては、何をどう書いてもいいのですが.........。2008年以降、PAMMを含む。メンテナンスも問題なし。しかし、搾取で...スプレッドが20まで拡大→マージン倍増→ギャップ→消灯...。すると、妻がタッチボタンについたホコリを拭いてくれるんです...。もういい加減にしてほしい。だから、この支店は中国にいるようなものなんです。 Реter Konow 2017.08.15 21:15 #377 СанСаныч Фоменко:関数を書くときに必ず問題になるのが1. 関数を作成する2. 別の関数を書いてみて、最初の関数とよく似ているが違うことがわかる。1つにまとめるべきか、2つに残すべきか、常にジレンマがあります。より多機能になったが、より複雑なコードを得ることができる。シンプルなコードなのに、たくさんの機能を手に入れることができます。このOOPはそういうものなんです。 うまく構成された明確なクラスを少数だけ割り当てることができれば。Expert Advisorをたくさん書くなら何らかの理由で修正することが多い場合次にOOPは便利です。私自身は、ソリューションの普遍性を追求しています。そのため、コードサイズを大きくすることなく、類似の機能を1つのブロックに「分割」する必要があります。これにより、機構の効率が上がり、過負荷や分割が不要になります。ちょっと頭を使うだけで、それだけでいいんです）。 つまり、20行ずつの関数が2つあったのです。どちらも似たような動作をしたり、似たような課題を解決したりします。私の目標は、両方の機能を実行する20行以下のコードで1つの関数を作ることです。ブロックはこのように表示されます。 Ihor Herasko 2017.08.15 21:16 #378 СанСаныч Фоменко:PS.昔は真珠のルビがあったんですよ。これが入っているんです。プログラムマニュアルは文書ではありません。マニュアルとは、プログラムの機能（プログラムができること）を説明したものです。ユーザーにとって必要なものです。ドキュメントとは、プログラムの構造（プログラムの作り方）を説明するものです。プログラマーにとって必要なことです。条件に抵触することはありません。 削除済み 2017.08.15 21:48 #379 СанСаныч Фоменко:...それがないのであれば、トレードと全く関係のない情報を頭に詰め込んでも意味がなく、Rに時間を 費やした方が良いのです。皆さんも頑張ってください。Rの 有効性を取引で実証する -- あなたはRに十分な時間を費やしました。コンテストに参加する - 1.9月、2.四半期ごとhttps://www.mql5.com/ru/forum/212596 Сентябрьская регистрация участников, на чемпионат реальных счетов (центы) - открыта 2017.08.02www.mql5.com Добро пожаловать... Dmitry Fedoseev 2017.08.15 22:25 #380 СанСаныч Фоменко:1.OOPを 使うことで、EAの収益性はどの程度向上しましたか？2.EAのMTBFはどの程度低下していますか？2.なんということでしょう)))) コンピュータプログラムのMTBFを...クリニック! 1...313233343536373839404142434445...48 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
私のOnInit()もほぼ同じで、十数行 です...
それで？
すげえええええええええええええええええええええええ
現代のプログラミングにおいて、カーネルのレベルで問題を混乱させる方法は他にあるのでしょうか？
これがプログラム全体であるということは...他には何もないですね :-)
もちろん、そんなことはありません。
灰＋Rで他全部（彼はカウントされない）
デバッグとは、2つのマスタの交点はあるが、信号はない、という論理のデバッグである。端末からの変数値把握に問題がある。ここで重要なのは、口座の種類を変えないこと、そしてできればブローカーを変えないことです。
ここで上に書かれてるような情熱は知らんけど。
もちろん、そんなことはありません。
灰＋Rで他全部（彼はカウントされない）
デバッグは、2つのマッシュの交点があるのに信号がないという、ロジックのデバッグが重要なのです。端末からの変数値把握に問題がある。ここで重要なのは、口座の種類を変えないこと、そしてできればブローカーを変えないことです。
上記のような情熱は一切意識していません。
ただぶっちゃけ、リアルアカウントは全くないのでしょうか？ 情熱はリアルとの出会いと搾取・保守のあざとさからきているだけで、テスターにとっては何をどう書いてもいいわけで......。
OOPは、機構の一部を分離し、包み込み、隠すための手法である。これが必要かどうかは、開発者の判断に委ねられます。機構の効率化とは全く関係ない。考え方の構造化ですね。正しく構成されているかは不明です。必要かどうかは、人それぞれです。
関数を書くときに必ず問題になるのが
1. 関数を作成する
2. 別の関数を書いてみて、非常に似ているが最初の関数とは違うことがわかる。
1つにまとめるべきか、2つに残すべきか、常にジレンマがあります。より多機能になったが、より複雑なコードを得ることができる。シンプルなコードなのに、たくさんの機能を手に入れることができます。このOOPはそういうものなんです。
うまく構成された明確なクラスを少数だけ割り当てることができれば。
Expert Advisorをたくさん 書くなら
何らかの理由で修正することが多い場合
次に
OOPは便利です。
そうでないなら、トレードとは関係ない情報で頭をいっぱいにする必要はなく、Rに時間を 費やした方が良いのではないでしょうか。
皆さんも頑張ってください。
ただ、率直に言って - 少なくとも1つの本当のアカウント？ 情熱は、現実世界との衝突と運用/保守のあざからくるもので、テスターにとっては、何をどう書いてもいいのですが.........。
2008年以降、PAMMを含む。
メンテナンスも問題なし。
しかし、搾取で...
スプレッドが20まで拡大→マージン倍増→ギャップ→消灯...。すると、妻がタッチボタンについたホコリを拭いてくれるんです...。もういい加減にしてほしい。だから、この支店は中国にいるようなものなんです。
関数を書くときに必ず問題になるのが
1. 関数を作成する
2. 別の関数を書いてみて、最初の関数とよく似ているが違うことがわかる。
1つにまとめるべきか、2つに残すべきか、常にジレンマがあります。より多機能になったが、より複雑なコードを得ることができる。シンプルなコードなのに、たくさんの機能を手に入れることができます。このOOPはそういうものなんです。
うまく構成された明確なクラスを少数だけ割り当てることができれば。
Expert Advisorをたくさん書くなら
何らかの理由で修正することが多い場合
次に
OOPは便利です。
私自身は、ソリューションの普遍性を追求しています。そのため、コードサイズを大きくすることなく、類似の機能を1つのブロックに「分割」する必要があります。これにより、機構の効率が上がり、過負荷や分割が不要になります。ちょっと頭を使うだけで、それだけでいいんです）。
つまり、20行ずつの関数が2つあったのです。どちらも似たような動作をしたり、似たような課題を解決したりします。私の目標は、両方の機能を実行する20行以下のコードで1つの関数を作ることです。ブロックはこのように表示されます。
PS.
昔は真珠のルビがあったんですよ。
これが入っているんです。
プログラムマニュアルは文書ではありません。
マニュアルとは、プログラムの機能（プログラムができること）を説明したものです。ユーザーにとって必要なものです。
ドキュメントとは、プログラムの構造（プログラムの作り方）を説明するものです。プログラマーにとって必要なことです。
条件に抵触することはありません。
...
それがないのであれば、トレードと全く関係のない情報を頭に詰め込んでも意味がなく、Rに時間を 費やした方が良いのです。
皆さんも頑張ってください。
Rの 有効性を取引で実証する -- あなたはRに十分な時間を費やしました。コンテストに参加する - 1.9月、2.四半期ごと
https://www.mql5.com/ru/forum/212596
1.OOPを 使うことで、EAの収益性はどの程度向上しましたか？
2.EAのMTBFはどの程度低下していますか？
2.なんということでしょう)))) コンピュータプログラムのMTBFを...クリニック!