MQL5におけるOOPに関する質問 - ページ 8 123456789101112131415...96 新しいコメント Artyom Trishkin 2019.07.05 07:57 #71 Igor Makanu: 削除を書き込まないでください - すべてが正しく動作します、この罪（私は迷信を意味する））。) がターミナルを引き継ぎ、ログに "48 bytes of leaked memory"、次に "2 objects of type CX left" と "undeleted objects left" とつぶやくでしょう。 HH:インジケータ・ テンプレートにDeinit()がない - これは迷惑だ ポインターではなく、オブジェクトを作ればいいのでは？端末のサブシステムがそれを追跡し、必要なときに釘を打つのです。 Artyom Trishkin 2019.07.05 08:01 #72 Dmitry Fedoseev: 削除しなくても動きますが、仕方ありません。しかし、この問題は端末が解決してくれるのでしょうか？メモリリークを報告するだけで、同じオブジェクトをデバッグすることはない。 ArrayObjやListなど、端末が知っているオブジェクトにnewで作成したオブジェクトへのポインタがスタックされている場合、端末が削除を担当します。 Igor Makanu 2019.07.05 08:03 #73 Artyom Trishkin: ポインターの代わりにオブジェクトを作ればいいのでは？端末のサブシステムがそれを追跡し、必要なときに釘を打つのです。 というのも、https://www.mql5.com/ru/forum/85652/page7#comment_12329866 アルチョム・トリシキン ArrayObj や List などのターミナルが知っているオブジェクトに、new で作成されたオブジェクトへのポインタがスタックされている場合、ターミナルが削除の処理をします。 は、常に便利な教師なし破壊ではありませんが、私は間違っているかもしれない、私はほとんどCObjectを使用しない、確認してみる必要があります。 Artyom Trishkin 2019.07.05 08:08 #74 Igor Makanu: というのも、https://www.mql5.com/ru/forum/85652/page7#comment_12329866 まあ、これは非常に特殊でグロテスクなほど単純化されたケースだと、私は思っています。変更できないオブジェクトを作り、そのフィールドを変更するためには、それを釘付けにして新しいものを作らなければならないように...。 また、いくつかのオブジェクトフィールドを変更し、他のフィールドには必要な情報を残しておく必要がある場合はどうでしょうか。IMHO - 銃を持って座り、くしゃみのたびにウサギを撃つよりも、それぞれのオブジェクトのインタラクティブ性と管理性に気を配る方が良い（継承のおかげで）。 しかし、公平を期すために、多数の中から1つを探し、それを変更するよりも、殺して新しいものを作る方が早い場合もあります。もちろん、直接リンクがあれば別ですが...。 Igor Makanu 2019.07.05 08:16 #75 Artyom Trishkin: まあ、これは非常に特殊でグロテスクに単純化されたケースだと、私は思っています。変更できないオブジェクトを作成し、そのフィールドの値を変更するために、それを釘付けにして新しいオブジェクトを作成すること...。 また、いくつかのオブジェクトフィールドを変更し、他のフィールドには必要な情報を残しておく必要がある場合はどうでしょうか。IMHO - 銃を持って座り、くしゃみのたびにウサギを撃つよりも、それぞれのオブジェクトのインタラクティブ性と管理性に気を配る方が良い（継承のおかげで）。 しかし、公平を期すために、多数の中から必要なものを探して変更するよりも、殺して新しいものを作ったほうが早い場合もあります。もちろん、直接のリンクがあれば別ですが...。 うーん、的外れだなあ......。はい、でもそんなことないですよ )))) 快適なものは何でも、それが使い道です- そして、「最初のc++の教科書」に載っているこれらの例は、あなたの経験の中でずっと引っ張り続けられるのです......。例えば、@fxsaber さんの コードのかなりの部分を分解して、無理やり #define をできるだけ多く使うようにしたところ、コードが短くなっただけでなく、本当に読みやすくなり、タイプミスもなくなりました。） アルチョム・トリシキン しかし、公平を期すために、多数の中から必要なものを探して変更するよりも、殺して新しいものを作ったほうが早い場合もあります。もちろん、直接の宛先がない場合は...。 と、本の基礎知識について...。プログラミングの「良い飼育ルール」によると、次のことが期待されています：変数を宣言してすぐに初期化すること（これによりデバッグ時のバグを回避できます）、OOPではコンストラクタがこれらの目的のために機能します - あなたはオブジェクトを作成してそれをすべて初期化します。 もし「単純なオブジェクトの後にコード全体を引っ張る」必要があるなら、すべてのクラスフィールドを再初期化するメソッドが必要になります - なぜこれを重複させるのでしょうか？- kill/create = result....が、やはり、好みや宗教の問題ですね。 Artyom Trishkin 2019.07.05 08:20 #76 Igor Makanu: というのも、https://www.mql5.com/ru/forum/85652/page7#comment_12329866 教師なし破壊は必ずしも快適ではありませんが、私が間違っているかもしれないので確認する必要があります。 でも、リストは使っていますね。そしてそれは、そこでも同じです。メモリ管理のFreeMode()のフラグがリストに対してリセットされていない限り、この場合、端末はトレースしませんが、すべてはユーザーが引き受けます。しかし、この状況はリストのコピーで変更、削除、ソート、その他の操作を行うために必要です。実際、リストはオブジェクトへのポインタで作成されており、リストの1つをコピーした新しいリストを作成し、新しいリストのオブジェクト（オブジェクトへのポインタがあります）を変更し始めると、元のリストのオブジェクトも変更されます（ポインタで作業するためです）。それは、オリジナルを保持し、彼のコピーをいじくり回すことです。それから、コピーのメモリ管理のフラグを落とす必要があります: FreeMode(false) - そうすれば、コピーは独立したコピーになり、オリジナルに影響を与えることなく、安全にその中のオブジェクトで作業することができます。また、ターミナルサブシステムからリストコピーをアンバインドした場合、リストオブジェクトの削除は自分たちの責任になることを忘れないでください。それを追跡し、OnDeinit()で削除することができます。これは最も単純なケースで、コピーリストが以前から知られている場合です。または、オブジェクトリストを作成し、手動メモリ管理のフラグで以前から知られていない、常に新しく作成したリストを配置します。すると、端末はこのリストオブジェクトを追跡し、その中に積み上げられたリストを正しく削除することができます。 Dmitry Fedoseev 2019.07.05 08:24 #77 Artyom Trishkin: 端末は、new で生成されたオブジェクトへのポインタが、端末が知っているオブジェクト (例: ArrayObj, List など) にスタックされている場合、その削除を引き継ぎます。 そうすれば、リークメッセージも発生しません。 Artyom Trishkin 2019.07.05 08:32 #78 Dmitry Fedoseev: それなら、流出したという報告もないでしょう。 そうですね、それはないでしょう。だって、漏れがないんだもん。 どこかで新しいオブジェクトを作成し、そのポインタを受け取った場合、与えられたポインタによってこのオブジェクトを削除しなければなりません。ポインターを追跡する必要があるということです。この目的のためには、SBで提供されている、オブジェクトへのポインタのリストや配列が非常に優れています。しかし、新しく作成されたオブジェクトのトラッキングやコントロールを行うことも可能です。しかし、私としては、すでに提供されているのであれば、なぜ大量のコードを書く必要があるのでしょうか？ Igor Makanu 2019.07.05 08:35 #79 Artyom Trishkin: であれば、このポインタによって、このオブジェクトを削除する必要があります。 しかし、私としては、すでに提供されているのであれば、なぜ大量のコードを書く必要があるのでしょうか？ 何トンのことでしょうか？ あなたが見逃したものはすべてターミナルから報告され、それを削除する場所も知られています - OnDeint() ...。つまり、この議論は、真空中の球形の馬の議論に帰結するのですね。))) Artyom Trishkin 2019.07.05 08:39 #80 Igor Makanu: ふ、ふざけんなよ......。みたいな、みたいな )))) 便利なものは便利、そんな使い方をしたいものです。- そして、これらの「最初のS++教科書」の例は、あなたの経験の中でずっと引っ張ることができる......。例えば、@fxsaber さんの コードのかなりの部分を分解して、自分もできるだけ #define を使うようにしたところ、コードが短くなっただけでなく、本当に読みやすくなり、誤字脱字もなくなりました。） そして、本の基礎知識について...。良い品種改良のルールは、変数を宣言してすぐに初期化することです（これにより、デバッグ時のバグを回避することができます）。 もし「単純なオブジェクトの後にコード全体を引っ張る」必要があるなら、 すべての クラスフィールドを 再初期化するメソッドが必要になります - なぜこれを重複させるのですか？- kill/create = result....が、やはり、好みや宗教の問題ですね。 オブジェクトの完全な再初期化ではなく、部分的な再初期化、つまり、いくつかのフィールドを変更する必要があり、残りの数十のフィールドには必要な情報がまだ格納されている場合です。フィールドを変更するかしないかは別として、変更する方法は必要です。もう一度言いますが、フィールドが1つの単純なオブジェクトについて話しているのであれば、話は別です。 2つ以上ある場合は、1つを変更し、他は変更しないようにする必要があります。 でも、もしかしたら話が違うかも？ 123456789101112131415...96 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
削除を書き込まないでください - すべてが正しく動作します、この罪（私は迷信を意味する））。) がターミナルを引き継ぎ、ログに "48 bytes of leaked memory"、次に "2 objects of type CX left" と "undeleted objects left" とつぶやくでしょう。
HH:インジケータ・ テンプレートにDeinit()がない - これは迷惑だ
ポインターではなく、オブジェクトを作ればいいのでは？端末のサブシステムがそれを追跡し、必要なときに釘を打つのです。
削除しなくても動きますが、仕方ありません。しかし、この問題は端末が解決してくれるのでしょうか？メモリリークを報告するだけで、同じオブジェクトをデバッグすることはない。
ArrayObjやListなど、端末が知っているオブジェクトにnewで作成したオブジェクトへのポインタがスタックされている場合、端末が削除を担当します。
ポインターの代わりにオブジェクトを作ればいいのでは？端末のサブシステムがそれを追跡し、必要なときに釘を打つのです。
というのも、https://www.mql5.com/ru/forum/85652/page7#comment_12329866
ArrayObj や List などのターミナルが知っているオブジェクトに、new で作成されたオブジェクトへのポインタがスタックされている場合、ターミナルが削除の処理をします。
は、常に便利な教師なし破壊ではありませんが、私は間違っているかもしれない、私はほとんどCObjectを使用しない、確認してみる必要があります。
というのも、https://www.mql5.com/ru/forum/85652/page7#comment_12329866
まあ、これは非常に特殊でグロテスクなほど単純化されたケースだと、私は思っています。変更できないオブジェクトを作り、そのフィールドを変更するためには、それを釘付けにして新しいものを作らなければならないように...。
また、いくつかのオブジェクトフィールドを変更し、他のフィールドには必要な情報を残しておく必要がある場合はどうでしょうか。IMHO - 銃を持って座り、くしゃみのたびにウサギを撃つよりも、それぞれのオブジェクトのインタラクティブ性と管理性に気を配る方が良い（継承のおかげで）。
しかし、公平を期すために、多数の中から1つを探し、それを変更するよりも、殺して新しいものを作る方が早い場合もあります。もちろん、直接リンクがあれば別ですが...。
まあ、これは非常に特殊でグロテスクに単純化されたケースだと、私は思っています。変更できないオブジェクトを作成し、そのフィールドの値を変更するために、それを釘付けにして新しいオブジェクトを作成すること...。
また、いくつかのオブジェクトフィールドを変更し、他のフィールドには必要な情報を残しておく必要がある場合はどうでしょうか。IMHO - 銃を持って座り、くしゃみのたびにウサギを撃つよりも、それぞれのオブジェクトのインタラクティブ性と管理性に気を配る方が良い（継承のおかげで）。
しかし、公平を期すために、多数の中から必要なものを探して変更するよりも、殺して新しいものを作ったほうが早い場合もあります。もちろん、直接のリンクがあれば別ですが...。
うーん、的外れだなあ......。はい、でもそんなことないですよ ))))
快適なものは何でも、それが使い道です- そして、「最初のc++の教科書」に載っているこれらの例は、あなたの経験の中でずっと引っ張り続けられるのです......。例えば、@fxsaber さんの コードのかなりの部分を分解して、無理やり #define をできるだけ多く使うようにしたところ、コードが短くなっただけでなく、本当に読みやすくなり、タイプミスもなくなりました。）
しかし、公平を期すために、多数の中から必要なものを探して変更するよりも、殺して新しいものを作ったほうが早い場合もあります。もちろん、直接の宛先がない場合は...。
と、本の基礎知識について...。プログラミングの「良い飼育ルール」によると、次のことが期待されています：変数を宣言してすぐに初期化すること（これによりデバッグ時のバグを回避できます）、OOPではコンストラクタがこれらの目的のために機能します - あなたはオブジェクトを作成してそれをすべて初期化します。
もし「単純なオブジェクトの後にコード全体を引っ張る」必要があるなら、すべてのクラスフィールドを再初期化するメソッドが必要になります - なぜこれを重複させるのでしょうか？- kill/create = result....が、やはり、好みや宗教の問題ですね。
というのも、https://www.mql5.com/ru/forum/85652/page7#comment_12329866
教師なし破壊は必ずしも快適ではありませんが、私が間違っているかもしれないので確認する必要があります。
でも、リストは使っていますね。そしてそれは、そこでも同じです。メモリ管理のFreeMode()のフラグがリストに対してリセットされていない限り、この場合、端末はトレースしませんが、すべてはユーザーが引き受けます。しかし、この状況はリストのコピーで変更、削除、ソート、その他の操作を行うために必要です。実際、リストはオブジェクトへのポインタで作成されており、リストの1つをコピーした新しいリストを作成し、新しいリストのオブジェクト（オブジェクトへのポインタがあります）を変更し始めると、元のリストのオブジェクトも変更されます（ポインタで作業するためです）。それは、オリジナルを保持し、彼のコピーをいじくり回すことです。それから、コピーのメモリ管理のフラグを落とす必要があります: FreeMode(false) - そうすれば、コピーは独立したコピーになり、オリジナルに影響を与えることなく、安全にその中のオブジェクトで作業することができます。また、ターミナルサブシステムからリストコピーをアンバインドした場合、リストオブジェクトの削除は自分たちの責任になることを忘れないでください。それを追跡し、OnDeinit()で削除することができます。これは最も単純なケースで、コピーリストが以前から知られている場合です。または、オブジェクトリストを作成し、手動メモリ管理のフラグで以前から知られていない、常に新しく作成したリストを配置します。すると、端末はこのリストオブジェクトを追跡し、その中に積み上げられたリストを正しく削除することができます。
端末は、new で生成されたオブジェクトへのポインタが、端末が知っているオブジェクト (例: ArrayObj, List など) にスタックされている場合、その削除を引き継ぎます。
そうすれば、リークメッセージも発生しません。
それなら、流出したという報告もないでしょう。
そうですね、それはないでしょう。だって、漏れがないんだもん。
どこかで新しいオブジェクトを作成し、そのポインタを受け取った場合、与えられたポインタによってこのオブジェクトを削除しなければなりません。ポインターを追跡する必要があるということです。この目的のためには、SBで提供されている、オブジェクトへのポインタのリストや配列が非常に優れています。しかし、新しく作成されたオブジェクトのトラッキングやコントロールを行うことも可能です。しかし、私としては、すでに提供されているのであれば、なぜ大量のコードを書く必要があるのでしょうか？
であれば、このポインタによって、このオブジェクトを削除する必要があります。
しかし、私としては、すでに提供されているのであれば、なぜ大量のコードを書く必要があるのでしょうか？
何トンのことでしょうか？ あなたが見逃したものはすべてターミナルから報告され、それを削除する場所も知られています - OnDeint() ...。つまり、この議論は、真空中の球形の馬の議論に帰結するのですね。)))
ふ、ふざけんなよ......。みたいな、みたいな ))))
便利なものは便利、そんな使い方をしたいものです。- そして、これらの「最初のS++教科書」の例は、あなたの経験の中でずっと引っ張ることができる......。例えば、@fxsaber さんの コードのかなりの部分を分解して、自分もできるだけ #define を使うようにしたところ、コードが短くなっただけでなく、本当に読みやすくなり、誤字脱字もなくなりました。）
そして、本の基礎知識について...。良い品種改良のルールは、変数を宣言してすぐに初期化することです（これにより、デバッグ時のバグを回避することができます）。
もし「単純なオブジェクトの後にコード全体を引っ張る」必要があるなら、 すべての クラスフィールドを 再初期化するメソッドが必要になります - なぜこれを重複させるのですか？- kill/create = result....が、やはり、好みや宗教の問題ですね。
オブジェクトの完全な再初期化ではなく、部分的な再初期化、つまり、いくつかのフィールドを変更する必要があり、残りの数十のフィールドには必要な情報がまだ格納されている場合です。フィールドを変更するかしないかは別として、変更する方法は必要です。もう一度言いますが、フィールドが1つの単純なオブジェクトについて話しているのであれば、話は別です。 2つ以上ある場合は、1つを変更し、他は変更しないようにする必要があります。
でも、もしかしたら話が違うかも？