OOPに関するヘルプ - ページ 4 123456789 新しいコメント Dmitry Fedoseev 2021.09.27 10:57 #31 Vasiliy Sokolov #:公式には、そうです。非公式には、多くのものがその存在を示しています。 MQLにはポインターがありません。その代わり、よく似たものに置き換わっています。 MQLでは、例えばC言語のような直接的なメモリ割り当てはありません。 MQLのプログラムは、ある仮想マシンで実行されます。レナートはそのことを簡潔に、一度も書かなかった。 クラスインスタンスを定義すると、自動的に解放されます。そこで、これらのインスタンスを監視し、必要なときに解放する何らかの仕組みが必要です。それがゴミ収集人でなくて何なのか？ ポインタを介して初期化され、適切に解放されなかったインスタンスは、終了時にリークオブジェクトとしてマークされます。その数と失われたメモリーの総容量が表示されます。リークしたメモリがあるプログラムは、Marketで検証すらされません。したがって、手動で割り当てられたものであっても、すべてのオブジェクトがシステムに計上され、知られており、知られている。これは、ゴミ収集員が解決する典型的な仕事の一つである。 エムクールにはゴミの収集家がいないことを示す十分かつ包括的な表示があります - 新規作成後は削除が必須です。 Georgiy Merts 2021.09.29 06:08 #32 Dmitry Fedoseev #:エムクールにはゴミの収集家がいないことを示す十分な証拠が一つあります - 新規作成後は削除が必須です。 私の記憶では、開発者の一人がゴミ収集係がいることを認めていたように思います。しかし、ユーザーにとっては「なんとなく存在しない」のです。 さて、新規・削除ペアについてですが、私は大賛成です。一般的には、リソースを要求したオブジェクトがその責任を負わなければならない。オブジェクト・ファクトリー」のような例外もありますが、そこでは、作成されたオブジェクトに対する責任は、ファクトリーにこれらのオブジェクトを要求した人にあることが明確に想定されています。 新しいものがあって削除が不要な言語では、「システムが不要なものを削除してしまう」という状況が嫌なんです。これは、（不要なオブジェクトがまだ削除されていないため）パフォーマンスを低下させる可能性があるだけでなく、コーダーをリラックスさせ、自分の行動の結果を気にしないようにするためでもあるのです。 Vasiliy Sokolov 2021.09.29 08:25 #33 Georgiy Merts #:newがあるのに、deleteが不要な言語では、「システムが不要なものを削除してくれる」という状況が本当に嫌です。これは、（不要なオブジェクトがまだ削除されていないため）パフォーマンスを低下させる可能性があるだけでなく、コーダーをリラックスさせ、自分の行動の結果を気にしないようにするためでもあるのです。 一方、生産性は概ね向上しています。手動で削除すると本スレで時間がかかる。+ 削除は要素ごとに行われます。例えば、このスレッドにある2つのバージョンのスクリプトを比べてみてください。速度の差は数倍。メモリ効率も上がる。集塵機は圧縮された物体を移動させるからです。手動で管理すると、空きメモリホールができてしまい、再利用が容易ではありません。さらに、ガベージコレクタは別のスレッドで動作しています。基本的な時間は無駄にはなりません。すべてにおいて、1プラス。 Dmitry Fedoseev 2021.09.29 08:52 #34 Vasiliy Sokolov #:それどころか、生産性は概して向上しています。手動での除去は、本流ではかなりの時間を要します。+ 削除は要素ごとに行われます。例えば、このスレッドにある2つのバージョンのスクリプトを比べてみてください。速度の差は数倍。メモリ効率も上がる。集塵機は圧縮された物体を移動させるからです。手動で管理すると、空きメモリホールができてしまい、再利用が容易ではありません。さらに、ガベージコレクタは別のスレッドで動作しています。基本的な時間は無駄にはなりません。すべてにおいて、プラスアルファとしか言いようがありません。 Vasily、申し訳ないが、あなたは自分が何を言おうとしているのか、まったく理解していない。まったくもって、そんなことはありません。 せめてウィキペディアでも読んでろよ、ゴミ収集員ってなんだよ。その最大の特徴は、通信が途絶えた対象物を除去することです。 ただ、この場合、ゴミ収集車と呼ばれることになる。この2つの脚本は、別の話です。神様の贈り物は、卵と混同してはいけないのです。 また、なぜガベージコレクタを使うと急に生産性が上がるのでしょうか？便利なコードとハードウェアの間にもう一つ水増しをしているようなもので、決して弱いものではありません。 Dmitry Fedoseev 2021.09.29 09:16 #35 Georgiy Merts #:私の記憶では、開発者の一人がゴミ収集係がいることを認めていました。しかし、ユーザーにとっては「なんとなく」なのです。/// これは、作業終了時にメモリリークに関するメッセージを出す「ガベージコレクタ」に違いない。 もしかしたら、放置されたオブジェクトを削除することもあるかもしれません。しかし、たとえそれが取り除かれたとしても、そこには大きな の違い - ジョブの終了時にのみ削除されます。また、数千回のサイクルで新しいオブジェクトが作られるとしたら？ 新しいオブジェクト？プログラムが動作不能になる、メモリが足りない。 本物のアセンブラは、プログラム操作中に失われたオブジェクトを削除するのでなく はプログラムの最後だけです。だからこそ、特別なプログラミングスタイルが許されるのです。 どんな条件下でも、どんな量でも、モノを掛け合わせることができる。 Georgiy Merts 2021.09.29 09:27 #36 Vasiliy Sokolov #:それどころか、生産性は概して向上しています。手動での削除は本流で多額な時間がかかる。+ 削除は要素ごとに行われます。例えば、このスレッドにある2つのバージョンのスクリプトを比べてみてください。速度の差は数倍。メモリ効率も上がる。集塵機は圧縮された物体を移動させるからです。手動で管理すると、空きメモリホールができてしまい、再利用が容易ではありません。さらに、ガベージコレクタは別のスレッドで動作しています。基本的な時間は無駄にはなりません。すべてにおいて、1プラス。 うーん...そして、ゴミ収集機では、削除は非要素？他のスレッドは、空きコアがない場合、同じコアで実行され、メインスレッドを遅くすることは言うまでもありません。 私の考えでは、一般的に、慎重に検討すれば、ユーザーによるゴミの除去は、ガベージコレクタによる除去よりも常に効率的だと思います。しかし、気にしなければ、確実にゴミ収集業者の勝ちです。 ガベージコレクタは、このようなリソースの無関心な扱いを助長してしまうので、私は好きではありません。 Georgiy Merts 2021.09.29 09:32 #37 Dmitry Fedoseev #:これは、ジョブが終了したときにメモリリークに関するメッセージを出す「アセンブラ」である必要があります。 おそらく、残ったオブジェクトも削除してしまうのでしょう。しかし、削除されても、大きな の違い - ジョブの終了時にのみ削除されます。また、数千回のサイクルで新しいオブジェクトが作られるとしたら？ 新しいオブジェクト？プログラムが動作不能になる、メモリが足りない。本物のアセンブラは、プログラム操作中に失われたオブジェクトを削除するのでなくはプログラムの最後だけです。だからこそ、特別なプログラミングスタイルが許されるのです。どんな条件下でも、どんな量でも、モノを掛け合わせることができる。 そうなんです。だから、私はアセンブラを使うのが好きではありません。ユーザーは、自分がどこにいくつのオブジェクトを作ったのか、注意を払わないからです。 基本的には、ビジー状態のものを忘れずに削除するという、ある意味、開発の簡略化にもなります。Builderは、オブジェクトが参照されなくなった瞬間を見つけ出して、それを削除する。でも、この立場は嫌になりますね。このような位置づけのため、プログラムの実行速度がどんどん遅くなり、同じような複雑さのタスクに対して、より強力なハードウェアリソースが必要になってきているのです。 Vasiliy Sokolov 2021.09.29 13:32 #38 Dmitry Fedoseev #:Vasilyさん、申し訳ありませんが、あなたは自分が何を主張しようとしているのか、まったく理解していません。まったく、何の意味もない。ドミトリー、失礼ですが、ムックル以外のプログラミング言語をご存知ですか？いいえ、そんなことはありません。そして、あなたはまだオブジェクトやポインタの扱い方を学んでいない。あなたが公開した数少ないコードや記事からもそれは明らかです。だから、この才能のない、はっきり言ってバカなコメントには、まともに返信もできないのです。最後にwikipediaを読み、ゴミ収集車が何であるか、どのように整理されているかを学び、最後にあなたが参照しようとしているものを少なくとも一度は読んでください。今のところ、すべてはキャラバンに吠える犬のように見えます：無分別で無慈悲な。 Vasiliy Sokolov 2021.09.29 13:41 #39 Georgiy Merts #:うーん...。また、ゴミ回収業者では削除は非要素化？別のスレッドが、空きコアがないときに - 同じコアによって行われ、メインスレッドの速度を低下させることは言うまでもありません。私の考えでは、一般的に、慎重に検討すれば、ユーザーによるゴミの除去は、ガベージコレクタによる除去よりも常に効率的だと思います。しかし、気にしなければ、確実にゴミ収集業者の勝ちです。だから私はガベージコレクタが好きではありません。ガベージコレクタは、このようにリソースを無関心に扱うことを助長します。 ガベージコレクタの動作を前提にするのではなく、オブジェクトの自動削除と手動削除の速度を比較すればよいのです。すべてのファンタジーが一挙に消え去る。 fxsaber 2021.09.29 13:42 #40 Vasiliy Sokolov #:自動オブジェクト削除と手動オブジェクト削除の速度を比較する。 答えは、できればすぐにでも。いつも実験する時間があるわけではありません。 123456789 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
公式には、そうです。非公式には、多くのものがその存在を示しています。
エムクールにはゴミの収集家がいないことを示す十分かつ包括的な表示があります - 新規作成後は削除が必須です。
エムクールにはゴミの収集家がいないことを示す十分な証拠が一つあります - 新規作成後は削除が必須です。
私の記憶では、開発者の一人がゴミ収集係がいることを認めていたように思います。しかし、ユーザーにとっては「なんとなく存在しない」のです。
さて、新規・削除ペアについてですが、私は大賛成です。一般的には、リソースを要求したオブジェクトがその責任を負わなければならない。オブジェクト・ファクトリー」のような例外もありますが、そこでは、作成されたオブジェクトに対する責任は、ファクトリーにこれらのオブジェクトを要求した人にあることが明確に想定されています。
新しいものがあって削除が不要な言語では、「システムが不要なものを削除してしまう」という状況が嫌なんです。これは、（不要なオブジェクトがまだ削除されていないため）パフォーマンスを低下させる可能性があるだけでなく、コーダーをリラックスさせ、自分の行動の結果を気にしないようにするためでもあるのです。
newがあるのに、deleteが不要な言語では、「システムが不要なものを削除してくれる」という状況が本当に嫌です。これは、（不要なオブジェクトがまだ削除されていないため）パフォーマンスを低下させる可能性があるだけでなく、コーダーをリラックスさせ、自分の行動の結果を気にしないようにするためでもあるのです。
一方、生産性は概ね向上しています。手動で削除すると本スレで時間がかかる。+ 削除は要素ごとに行われます。例えば、このスレッドにある2つのバージョンのスクリプトを比べてみてください。速度の差は数倍。メモリ効率も上がる。集塵機は圧縮された物体を移動させるからです。手動で管理すると、空きメモリホールができてしまい、再利用が容易ではありません。さらに、ガベージコレクタは別のスレッドで動作しています。基本的な時間は無駄にはなりません。すべてにおいて、1プラス。
それどころか、生産性は概して向上しています。手動での除去は、本流ではかなりの時間を要します。+ 削除は要素ごとに行われます。例えば、このスレッドにある2つのバージョンのスクリプトを比べてみてください。速度の差は数倍。メモリ効率も上がる。集塵機は圧縮された物体を移動させるからです。手動で管理すると、空きメモリホールができてしまい、再利用が容易ではありません。さらに、ガベージコレクタは別のスレッドで動作しています。基本的な時間は無駄にはなりません。すべてにおいて、プラスアルファとしか言いようがありません。
Vasily、申し訳ないが、あなたは自分が何を言おうとしているのか、まったく理解していない。まったくもって、そんなことはありません。
せめてウィキペディアでも読んでろよ、ゴミ収集員ってなんだよ。その最大の特徴は、通信が途絶えた対象物を除去することです。
ただ、この場合、ゴミ収集車と呼ばれることになる。この2つの脚本は、別の話です。神様の贈り物は、卵と混同してはいけないのです。
また、なぜガベージコレクタを使うと急に生産性が上がるのでしょうか？便利なコードとハードウェアの間にもう一つ水増しをしているようなもので、決して弱いものではありません。
私の記憶では、開発者の一人がゴミ収集係がいることを認めていました。しかし、ユーザーにとっては「なんとなく」なのです。
///
これは、作業終了時にメモリリークに関するメッセージを出す「ガベージコレクタ」に違いない。
もしかしたら、放置されたオブジェクトを削除することもあるかもしれません。しかし、たとえそれが取り除かれたとしても、そこには大きな
の違い - ジョブの終了時にのみ削除されます。また、数千回のサイクルで新しいオブジェクトが作られるとしたら？
新しいオブジェクト？プログラムが動作不能になる、メモリが足りない。
本物のアセンブラは、プログラム操作中に失われたオブジェクトを削除するのでなく
はプログラムの最後だけです。だからこそ、特別なプログラミングスタイルが許されるのです。
どんな条件下でも、どんな量でも、モノを掛け合わせることができる。
それどころか、生産性は概して向上しています。手動での削除は本流で多額な時間がかかる。+ 削除は要素ごとに行われます。例えば、このスレッドにある2つのバージョンのスクリプトを比べてみてください。速度の差は数倍。メモリ効率も上がる。集塵機は圧縮された物体を移動させるからです。手動で管理すると、空きメモリホールができてしまい、再利用が容易ではありません。さらに、ガベージコレクタは別のスレッドで動作しています。基本的な時間は無駄にはなりません。すべてにおいて、1プラス。
うーん...そして、ゴミ収集機では、削除は非要素？他のスレッドは、空きコアがない場合、同じコアで実行され、メインスレッドを遅くすることは言うまでもありません。
私の考えでは、一般的に、慎重に検討すれば、ユーザーによるゴミの除去は、ガベージコレクタによる除去よりも常に効率的だと思います。しかし、気にしなければ、確実にゴミ収集業者の勝ちです。
ガベージコレクタは、このようなリソースの無関心な扱いを助長してしまうので、私は好きではありません。
これは、ジョブが終了したときにメモリリークに関するメッセージを出す「アセンブラ」である必要があります。
おそらく、残ったオブジェクトも削除してしまうのでしょう。しかし、削除されても、大きな
の違い - ジョブの終了時にのみ削除されます。また、数千回のサイクルで新しいオブジェクトが作られるとしたら？
新しいオブジェクト？プログラムが動作不能になる、メモリが足りない。
本物のアセンブラは、プログラム操作中に失われたオブジェクトを削除するのでなく
はプログラムの最後だけです。だからこそ、特別なプログラミングスタイルが許されるのです。
どんな条件下でも、どんな量でも、モノを掛け合わせることができる。
そうなんです。だから、私はアセンブラを使うのが好きではありません。ユーザーは、自分がどこにいくつのオブジェクトを作ったのか、注意を払わないからです。
基本的には、ビジー状態のものを忘れずに削除するという、ある意味、開発の簡略化にもなります。Builderは、オブジェクトが参照されなくなった瞬間を見つけ出して、それを削除する。でも、この立場は嫌になりますね。このような位置づけのため、プログラムの実行速度がどんどん遅くなり、同じような複雑さのタスクに対して、より強力なハードウェアリソースが必要になってきているのです。
Vasilyさん、申し訳ありませんが、あなたは自分が何を主張しようとしているのか、まったく理解していません。まったく、何の意味もない。
うーん...。また、ゴミ回収業者では削除は非要素化？別のスレッドが、空きコアがないときに - 同じコアによって行われ、メインスレッドの速度を低下させることは言うまでもありません。
私の考えでは、一般的に、慎重に検討すれば、ユーザーによるゴミの除去は、ガベージコレクタによる除去よりも常に効率的だと思います。しかし、気にしなければ、確実にゴミ収集業者の勝ちです。
だから私はガベージコレクタが好きではありません。ガベージコレクタは、このようにリソースを無関心に扱うことを助長します。
ガベージコレクタの動作を前提にするのではなく、オブジェクトの自動削除と手動削除の速度を比較すればよいのです。すべてのファンタジーが一挙に消え去る。
自動オブジェクト削除と手動オブジェクト削除の速度を比較する。
答えは、できればすぐにでも。いつも実験する時間があるわけではありません。