MQL4、MQL5に関する初心者からの質問、アルゴリズムやコードに関するヘルプ、ディスカッションなど。 - ページ 596 1...589590591592593594595596597598599600601602603...1953 新しいコメント Artyom Trishkin 2018.08.08 21:40 #5951 Juer:わかりました。OnDeinit()で削除させてください。でも、今はもうテスト中にメモリ不足のエラーが出るようになってしまって...。つまり、OnDeinit()までたどり着けません。だから、ダブルのオブジェクトをたくさん作ることになる。そうすると、すべてが地獄に落ちて、終わりが分からなくなる。 Juer 2018.08.08 21:56 #5952 Artyom Trishkin:つまり、重複したオブジェクトを大量に作ってしまうわけです。そうすると、全体が見えなくなり、最後がわからなくなる。オブジェクトを削除していない場所を正確に知るにはどうしたらよいですか?大きなプログラムです :) Artyom Trishkin 2018.08.08 21:59 #5953 Juer:オブジェクトを削除していない場所を正確に知るにはどうしたらよいですか?大きなプログラムです :)まず、どこでどのようにそのような山を作ったかを調べる必要があります。記憶が正しければ、1万個くらいはあるんじゃないですか?どんなものですか?過去のデータオブジェクトなのか?あるいは、どんなモノがそんなにたくさんあるのか?オブジェクトの配列 - どのような? Juer 2018.08.08 22:03 #5954 Artyom Trishkin:まず、どこでどのようにそのような山を作ったかを調べる必要があります。記憶が正しければ、そこに何万個もあるんでしょう?どんなものですか?歴史的なデータのオブジェクト?あるいは、どんなモノがそんなにたくさんあるのか?オブジェクトの配列 - どのような?あ、いろいろ入ってますね。主にキャンドルの種類と ルール。複雑なんです )) Konstantin Nikitin 2018.08.08 22:06 #5955 Juer:オブジェクトを削除していない場所を正確に知るにはどうしたらよいですか?大きなプログラムです :)ティックごとに新しいオブジェクトを作成するわけではありません。もちろんそれは可能ですが(しかし、私の意見では常に合理的とは言え ません)、オブジェクトの作業を 終えたらすぐにデフレートする方が合理的であるはずです。これくらいしか説明がつかない。 Artyom Trishkin 2018.08.08 22:08 #5956 Juer:あ、いろいろ入ってますね。主にキャンドルの種類と ルール。複雑なんです ))ある人には複雑で、ある人にはそうでない。しかし、今、それを整理するのはあなた次第です。 ひとことお願いします。ゼロから始める。TFを変更したときや再コンパイルしたときに、ログに未削除のオブジェクトやメモリリークに関するメッセージが表示されたら、それを修正します。次に、すべてのオブジェクトが正しく保存、使用、削除されているかどうかをチェックする機能を追加します。newで作成した場合は、自分で削除する必要があります。 Juer 2018.08.08 22:24 #5957 Konstantin Nikitin:ティックごとに新しいオブジェクトが作られるわけではありませんよね?可能ですが(私の意見では、常に合理的とは 言えません)、オブジェクトの作業を終えたらすぐに デフレートする方が合理的でしょう。それくらいしか説明がつかない。それぞれのキャンドルに Konstantin Nikitin 2018.08.08 22:28 #5958 Juer:それぞれのキャンドルにまあ、前のオブジェクトが必要ないのであれば、素直に削除するのが得策です。 Juer 2018.08.08 22:30 #5959 Konstantin Nikitin:まあ、前のオブジェクトが必要ないのであれば、一旦削除した方が良いですね。そう、そこなんです。オブジェクトが他のオブジェクトの中に入っていて、もう簡単に削除できないので、とてもわかりにくいです。あるオブジェクトは他のオブジェクトに依存し、そのオブジェクトは最初のオブジェクトに依存する第3のオブジェクトに依存する :) 人生はとても複雑だ :( Artyom Trishkin 2018.08.08 22:37 #5960 Juer:そう、そこなんです。オブジェクトが他のオブジェクトの中に入っていて、もう簡単に削除できないので、とてもわかりにくいです。あるオブジェクトは他のオブジェクトに依存し、そのオブジェクトは最初のオブジェクトに依存する第3のオブジェクトに依存する :)人生はとても複雑だ :(ごっちゃになってますね。タスクのプランニングを誤ると、まさにそのような結果になるのです。 クラス内でオブジェクトが生成された場合、そのクラスは終了時にデストラクタでオブジェクトを削除しなければなりません。他のクラスは、オブジェクトへのポインタを取得する 前に、そのオブジェクトが有効であるかどうかを確認する必要があります。そして、原則的にそのような絡み合った関係はないはずです。ちょっと絡んでますね。複雑なのは品質ではありません。すべてが透明で、追跡可能であるべきです。まず第一に、あなたのために。 1...589590591592593594595596597598599600601602603...1953 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
わかりました。OnDeinit()で削除させてください。でも、今はもうテスト中にメモリ不足のエラーが出るようになってしまって...。つまり、OnDeinit()までたどり着けません。
だから、ダブルのオブジェクトをたくさん作ることになる。そうすると、すべてが地獄に落ちて、終わりが分からなくなる。
つまり、重複したオブジェクトを大量に作ってしまうわけです。そうすると、全体が見えなくなり、最後がわからなくなる。
オブジェクトを削除していない場所を正確に知るにはどうしたらよいですか?大きなプログラムです :)
オブジェクトを削除していない場所を正確に知るにはどうしたらよいですか?大きなプログラムです :)
まず、どこでどのようにそのような山を作ったかを調べる必要があります。記憶が正しければ、1万個くらいはあるんじゃないですか?どんなものですか?過去のデータオブジェクトなのか?あるいは、どんなモノがそんなにたくさんあるのか?オブジェクトの配列 - どのような?
まず、どこでどのようにそのような山を作ったかを調べる必要があります。記憶が正しければ、そこに何万個もあるんでしょう?どんなものですか?歴史的なデータのオブジェクト?あるいは、どんなモノがそんなにたくさんあるのか?オブジェクトの配列 - どのような?
あ、いろいろ入ってますね。主にキャンドルの種類と ルール。複雑なんです ))
オブジェクトを削除していない場所を正確に知るにはどうしたらよいですか?大きなプログラムです :)
ティックごとに新しいオブジェクトを作成するわけではありません。もちろんそれは可能ですが(しかし、私の意見では常に合理的とは言え ません)、オブジェクトの作業を 終えたらすぐにデフレートする方が合理的であるはずです。これくらいしか説明がつかない。
あ、いろいろ入ってますね。主にキャンドルの種類と ルール。複雑なんです ))
ある人には複雑で、ある人にはそうでない。しかし、今、それを整理するのはあなた次第です。
ひとことお願いします。ゼロから始める。TFを変更したときや再コンパイルしたときに、ログに未削除のオブジェクトやメモリリークに関するメッセージが表示されたら、それを修正します。次に、すべてのオブジェクトが正しく保存、使用、削除されているかどうかをチェックする機能を追加します。newで作成した場合は、自分で削除する必要があります。
ティックごとに新しいオブジェクトが作られるわけではありませんよね?可能ですが(私の意見では、常に合理的とは 言えません)、オブジェクトの作業を終えたらすぐに デフレートする方が合理的でしょう。それくらいしか説明がつかない。
それぞれのキャンドルに
それぞれのキャンドルに
まあ、前のオブジェクトが必要ないのであれば、素直に削除するのが得策です。
まあ、前のオブジェクトが必要ないのであれば、一旦削除した方が良いですね。
そう、そこなんです。オブジェクトが他のオブジェクトの中に入っていて、もう簡単に削除できないので、とてもわかりにくいです。あるオブジェクトは他のオブジェクトに依存し、そのオブジェクトは最初のオブジェクトに依存する第3のオブジェクトに依存する :)
人生はとても複雑だ :(
そう、そこなんです。オブジェクトが他のオブジェクトの中に入っていて、もう簡単に削除できないので、とてもわかりにくいです。あるオブジェクトは他のオブジェクトに依存し、そのオブジェクトは最初のオブジェクトに依存する第3のオブジェクトに依存する :)
人生はとても複雑だ :(
ごっちゃになってますね。タスクのプランニングを誤ると、まさにそのような結果になるのです。
クラス内でオブジェクトが生成された場合、そのクラスは終了時にデストラクタでオブジェクトを削除しなければなりません。他のクラスは、オブジェクトへのポインタを取得する 前に、そのオブジェクトが有効であるかどうかを確認する必要があります。そして、原則的にそのような絡み合った関係はないはずです。ちょっと絡んでますね。複雑なのは品質ではありません。すべてが透明で、追跡可能であるべきです。まず第一に、あなたのために。