初心者の方からの質問 MQL5 MT5 MetaTrader 5 - ページ 192 1...185186187188189190191192193194195196197198199...1503 新しいコメント Maxim Khrolenko 2014.02.09 18:00 #1911 OOPの勉強を始めたのですが、次のような障害を乗り越えられません。以下のスクリプトはその一例です。CSum result; void OnStart() { //--- } //+----------------------------------------+ class CSum { public: int Calculate(int A,int B); }; //--- int CSum::Calculate(int A,int B) { return(A+B); }CSum result;」という行がなければ、コンパイラはエラーを発生させない。しかし、エラーになる。どうしたのか教えてください。クラスオブジェクトを 正しく宣言しているようです。 Vasiliy Sokolov 2014.02.09 18:25 #1912 paladin800:OOPの勉強を始めたのですが、次のような障害を乗り越えられません。以下のスクリプトはその一例です。CSum result;」という行がなければ、コンパイラはエラーを発生させない。しかし、エラーになる。どうしたのか教えてください。クラスオブジェクトを 正しく宣言しているようです。 CSum（結果）型の変数は、CSumの記述が行われる前に宣言されるため、コンパイラはまだこの型を知らないことになる。CSumをファイルの一番最初に挿入する。 Vasiliy Sokolov 2014.02.09 18:30 #1913 Lone_Irbis: また、グローバル変数 システムはどの程度活用できるのか/すべきなのか。このように何かをオーバーロードすることは可能なのでしょうか、それとも限界があるのでしょうか。例えば、2つ以上の数百の変数（そのうち約半分は入力に変わり、テストが必要なコードの断片によります）と、グローバルレベルの小さな配列が10数個あるとします - それは多いでしょうか、少ないでしょうか？^^' また、微調整していくうちに2倍、3倍と増えていったらどうでしょう？また、そんなに浮かれる必要はないとしても、お互いの結果を必要とする多くの異なるサブシステム間のデータ交換を扱うのに、もっとシンプルな方法はないのでしょうか？ いや、ないですね。グローバル変数は他の目的に使用されます。サブシステムを記述するためにクラスを使用する。また、配列やグローバル変数の使用は完全に避けた方がよいでしょう。 Maxim Khrolenko 2014.02.09 18:38 #1914 C-4: CSum型の変数（result）-は、CSumの記述がなされる前に宣言されているので、コンパイラはまだこの型を知らないということです。CSumをファイルの一番最初に挿入する。 おっと、うまくいきましたね。関数の配置になぞらえて、クラスをコードの末尾に配置しました。まさか、授業でこのような注文が出るとは思いませんでした。 Vasiliy Sokolov 2014.02.09 18:58 #1915 paladin800: おっと、うまくいきましたね。関数の配置と同じように、コードの末尾にクラスを配置しました。まさか、そんな注文でクラスに差が出るとは思ってもいませんでした。 はい、残念ながら優先順位は重要です。最も難しいケースは、2つのクラスが同時に使用する場合です。どのクラスを先に導入しても、2番目のクラスはコンパイラにとって未知のクラスであり、エラーが発生する。この場合、クラス宣言をしないわけにはいきません。あなたの場合、CSumを別ファイル、例えばSum.mqhに分離して、#include "Sum.mqh "のディクテーションでインクルードするのが良いでしょう。 Lone_Irbis 2014.02.09 22:34 #1916 C-4: いや、そんなことはないはずだ。グローバル変数は他の目的に使用されます。サブシステムを記述するためにクラスを使用する。また、配列やグローバル変数は全く使わない方が良い。 もちろん、クラスを使うのが良いというのは理解しているのですが、やはりクラスがない方が馴染みますし、どう考えてもうまくいきそうなことを考えると、なんとなく億劫になってしまいます。ただ、気になるのは、彼らのアドバンテージは何なのか、ということです。ただし、そのコードが一人の作者によって自分のためだけに書かれたもので、特定のプログラムの外では決して有用でないことが確実に分かっている場合に限りますが。授業は、誰かのために、何かのために、売るために書く場合にのみ意味があり、自分自身のための趣味では、あまり違いがないようにいつも思います。美学や一般的な「まあまあ」は別として、これらのクラス構造すべてに関与する実用的な意味はあるのでしょうか？スピード？他に何か？ Artyom Trishkin 2014.02.09 22:51 #1917 Lone_Irbis: もちろん、クラスを扱うといいというのは理解しているのですが、それでもクラスがない方が馴染みがいいし、とりあえず動いているように見えることを考えると、億劫になってしまうのです。ただ、気になるのは、彼らのアドバンテージは何なのか、ということです。ただし、そのコードが一人の作者によって自分のためだけに書かれたもので、特定のプログラムの外では決して有用でないことが確実に分かっている場合に限りますが。授業は、誰かのために、何かのために、売るために書く場合にのみ意味があり、自分自身のための趣味では、あまり違いがないようにいつも思います。美学や一般的な「まあまあ」は別として、これらのクラス構造すべてに関与する実用的な意味はあるのでしょうか？スピード？他に何か？それどころかカスタム案件を書くと、お客様からソースコードを要求されることが多い。そして、クラスから関数を引き出して、ソースコードに挿入しなければなりません。お客さまにお渡しする作品には使われていない、膨大な数の関数を含むライブラリーを山ほど引きずり込むよりも、1つのファイルをお渡ししたほうがよいでしょう。つまり、構造化プログラミングをオンデマンドで使用するのが良いのです。自分のニーズに合わせて、OOPを使うのがよいでしょう。そこではすべてが自己完結していますし、ソースコードの受け渡しに悩まされることもありません。 Lone_Irbis 2014.02.10 00:16 #1918 artmedia70:それどころかカスタムプロジェクトを書く場合、顧客からソースコードを要求されることが多い。そして、クラスから関数を引き出して、ソースコードに挿入しなければなりません。お客さまにお渡しする作品には使われていない、膨大な数の関数を含むライブラリーを山ほど引きずり込むよりも、1つのファイルをお渡ししたほうがよいでしょう。つまり、お客さんには構造化プログラミングを使った方がいいんです。自分のニーズに合わせてOOPを使う方がいい。自分のものはすべてそこにあるし、わざわざソースコードを転送する必要もない。うーん...。まあ、そうかもしれませんね :)それはもちろん、原理が魅力的に見えるからですが...。理論的には特に、構造体やクラスがない1つのファイルを作ることができないことを考慮すると。つまり、私はほとんど興味本位で書いていて、自分自身のランダムな理論を検証したり、無限の自転車を発明したりしているのです。それと並行して、アイデアを実現するために必要なことが始まっていることだけを勉強しています。これらはすべて、1つの学習・実験用Expert Advisorの枠組みの中で起こっています。最初はシンプルなマーチンでしたが、今では多機能なスキャルパーの芽が出ています（そしてすでに理論的には利益を上げています）。だから、ある時期からロボットが些細なことで大きくなりすぎてしまったんです。>このような状況下で、私は、「このようなコードを別個のファイル（現時点では13個のパーツが接続可能）にして、大まかなコンセプトごとに関数をグループ化する」という「天才的」なアイデアを思いつきました。ニュースパーサはここ、レベル処理はここ、ムースコントローラは別、統計は別、といった具合です。しかし、当時はOOPに取り組む熱意が足りず...。私の問題は、思いつく限りのアイデアを集めて、既存のロボットの上に完成させるという、かなり...カオスシーケンスその結果、あらゆる種類のスイッチやモードの組み合わせがあり、その多くがやりっぱなしという、かなり奇抜なものになっています。全体像は、入力から削除しなければならない150個のグローバル 変数によって補完され、テスターのビジュアライザーに最初に刷り込まれます。もちろん、ゴミの山や、捨てられたり、デザインし直されたりしたアイデアの初歩もあります。そして、このゴミの山を整理して、すべてをクラスにまとめるのに良い時期だと思います（そして、まず、その過程で眠くならないように、少なくとも1つのOOPに関する記事を読みます）......。しかし、やるべきことの多さと、エヘン、全体の潜在的な意味との関係で戸惑っているのです。それは、クラスですべてを結論づけることです。それは、それほどボリューム感のあるタスクではないようです。しかし、例えば、これらのプライベート/プロテクトをすべて無視して、一列に並んだすべてをパブリックにダンプすることは、意味があるのでしょうか？どうせ1つのロボットに集約されるなら、.mphの束と共通機能をそれぞれ十数個持っているフォルダーを持つより、その方がいいのでは？ Artyom Trishkin 2014.02.10 00:27 #1919 Lone_Irbis:初期化、接続、常に必要なデータの収集など、必要なステップをすでに持っている単一のテンプレートを作成することをお勧めします。テンプレートを読み込んで名前を変え、その中に今回のアイデアに関連することだけを書き込むという、思いがけないアイデアが浮かんだのです。そして、どんなコードでもいつも使っていて、どんな状況でも同じデータを返すような関数は、クラスに入れてしまいましょう。そして、すべてが一度に収まるようになるのです。また、ディレクトリを構造化することもできます。\experts⑷では、Ordersというフォルダを作成し、そこに別の顧客に属するすべてのファイルを別々のフォルダに入れ、Ideas、Testsなどのフォルダを作成しています。そうすることで、整理整頓ができるのです。 Vasiliy Sokolov 2014.02.10 09:51 #1920 残念ながら、形式的にOOPを学んでも、OOPのプログラムを作ることはできません。むしろ、このアプローチの哲学に触れる必要があり、これは形式的な知識を得た後の次のレベルです。それでわかったのは、本当に必要なのか？でも、「どうしたらいいのか」と質問してくるということは、自分が選んだやり方が最適ではないと感じているのでしょう。いずれにせよ、選ぶのはあなた自身です。 1...185186187188189190191192193194195196197198199...1503 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
OOPの勉強を始めたのですが、次のような障害を乗り越えられません。以下のスクリプトはその一例です。
CSum result;」という行がなければ、コンパイラはエラーを発生させない。しかし、エラーになる。
どうしたのか教えてください。クラスオブジェクトを 正しく宣言しているようです。
OOPの勉強を始めたのですが、次のような障害を乗り越えられません。以下のスクリプトはその一例です。
CSum result;」という行がなければ、コンパイラはエラーを発生させない。しかし、エラーになる。
どうしたのか教えてください。クラスオブジェクトを 正しく宣言しているようです。
また、グローバル変数 システムはどの程度活用できるのか/すべきなのか。このように何かをオーバーロードすることは可能なのでしょうか、それとも限界があるのでしょうか。例えば、2つ以上の数百の変数（そのうち約半分は入力に変わり、テストが必要なコードの断片によります）と、グローバルレベルの小さな配列が10数個あるとします - それは多いでしょうか、少ないでしょうか？^^' また、微調整していくうちに2倍、3倍と増えていったらどうでしょう？また、そんなに浮かれる必要はないとしても、お互いの結果を必要とする多くの異なるサブシステム間のデータ交換を扱うのに、もっとシンプルな方法はないのでしょうか？
CSum型の変数（result）-は、CSumの記述がなされる前に宣言されているので、コンパイラはまだこの型を知らないということです。CSumをファイルの一番最初に挿入する。
おっと、うまくいきましたね。関数の配置と同じように、コードの末尾にクラスを配置しました。まさか、そんな注文でクラスに差が出るとは思ってもいませんでした。
いや、そんなことはないはずだ。グローバル変数は他の目的に使用されます。サブシステムを記述するためにクラスを使用する。また、配列やグローバル変数は全く使わない方が良い。
もちろん、クラスを扱うといいというのは理解しているのですが、それでもクラスがない方が馴染みがいいし、とりあえず動いているように見えることを考えると、億劫になってしまうのです。ただ、気になるのは、彼らのアドバンテージは何なのか、ということです。ただし、そのコードが一人の作者によって自分のためだけに書かれたもので、特定のプログラムの外では決して有用でないことが確実に分かっている場合に限りますが。授業は、誰かのために、何かのために、売るために書く場合にのみ意味があり、自分自身のための趣味では、あまり違いがないようにいつも思います。美学や一般的な「まあまあ」は別として、これらのクラス構造すべてに関与する実用的な意味はあるのでしょうか？スピード？他に何か？
それどころかカスタム案件を書くと、お客様からソースコードを要求されることが多い。そして、クラスから関数を引き出して、ソースコードに挿入しなければなりません。お客さまにお渡しする作品には使われていない、膨大な数の関数を含むライブラリーを山ほど引きずり込むよりも、1つのファイルをお渡ししたほうがよいでしょう。つまり、構造化プログラミングをオンデマンドで使用するのが良いのです。
自分のニーズに合わせて、OOPを使うのがよいでしょう。そこではすべてが自己完結していますし、ソースコードの受け渡しに悩まされることもありません。
それどころかカスタムプロジェクトを書く場合、顧客からソースコードを要求されることが多い。そして、クラスから関数を引き出して、ソースコードに挿入しなければなりません。お客さまにお渡しする作品には使われていない、膨大な数の関数を含むライブラリーを山ほど引きずり込むよりも、1つのファイルをお渡ししたほうがよいでしょう。つまり、お客さんには構造化プログラミングを使った方がいいんです。
自分のニーズに合わせてOOPを使う方がいい。自分のものはすべてそこにあるし、わざわざソースコードを転送する必要もない。
うーん...。まあ、そうかもしれませんね :)それはもちろん、原理が魅力的に見えるからですが...。理論的には特に、構造体やクラスがない1つのファイルを作ることができないことを考慮すると。つまり、私はほとんど興味本位で書いていて、自分自身のランダムな理論を検証したり、無限の自転車を発明したりしているのです。それと並行して、アイデアを実現するために必要なことが始まっていることだけを勉強しています。これらはすべて、1つの学習・実験用Expert Advisorの枠組みの中で起こっています。最初はシンプルなマーチンでしたが、今では多機能なスキャルパーの芽が出ています（そしてすでに理論的には利益を上げています）。だから、ある時期からロボットが些細なことで大きくなりすぎてしまったんです。>このような状況下で、私は、「このようなコードを別個のファイル（現時点では13個のパーツが接続可能）にして、大まかなコンセプトごとに関数をグループ化する」という「天才的」なアイデアを思いつきました。ニュースパーサはここ、レベル処理はここ、ムースコントローラは別、統計は別、といった具合です。しかし、当時はOOPに取り組む熱意が足りず...。
私の問題は、思いつく限りのアイデアを集めて、既存のロボットの上に完成させるという、かなり...カオスシーケンスその結果、あらゆる種類のスイッチやモードの組み合わせがあり、その多くがやりっぱなしという、かなり奇抜なものになっています。全体像は、入力から削除しなければならない150個のグローバル 変数によって補完され、テスターのビジュアライザーに最初に刷り込まれます。もちろん、ゴミの山や、捨てられたり、デザインし直されたりしたアイデアの初歩もあります。
そして、このゴミの山を整理して、すべてをクラスにまとめるのに良い時期だと思います（そして、まず、その過程で眠くならないように、少なくとも1つのOOPに関する記事を読みます）......。しかし、やるべきことの多さと、エヘン、全体の潜在的な意味との関係で戸惑っているのです。それは、クラスですべてを結論づけることです。それは、それほどボリューム感のあるタスクではないようです。しかし、例えば、これらのプライベート/プロテクトをすべて無視して、一列に並んだすべてをパブリックにダンプすることは、意味があるのでしょうか？どうせ1つのロボットに集約されるなら、.mphの束と共通機能をそれぞれ十数個持っているフォルダーを持つより、その方がいいのでは？
初期化、接続、常に必要なデータの収集など、必要なステップをすでに持っている単一のテンプレートを作成することをお勧めします。
テンプレートを読み込んで名前を変え、その中に今回のアイデアに関連することだけを書き込むという、思いがけないアイデアが浮かんだのです。そして、どんなコードでもいつも使っていて、どんな状況でも同じデータを返すような関数は、クラスに入れてしまいましょう。そして、すべてが一度に収まるようになるのです。また、ディレクトリを構造化することもできます。\experts⑷では、Ordersというフォルダを作成し、そこに別の顧客に属するすべてのファイルを別々のフォルダに入れ、Ideas、Testsなどのフォルダを作成しています。
そうすることで、整理整頓ができるのです。