私は問題の要点を理解していると思いますが (つまり、優れた GCはscopeではなくobjectsを追跡します)、他の人を説得するのに十分な知識がありません。
決定論的デストラクタを持つガベージ コレクション言語がない理由について説明してもらえますか?
3 に答える
3
それらは相互に排他的ではありません。libgc (Boehm-Reiser-Detlefs コレクター) で C++ を自由に使用してください。RAII、スマート ポインター、および手動削除は引き続き使用できますが、GC を実行していると、一部のオブジェクトを削除することを「忘れる」こともできます。
リソースの破棄が遅すぎるという@Andyの回答は、重要な点を見逃しています。意味的に重要なのはリソースのリリースの遅延ではなく、リリースの順序です。
GC がリリースを適切に順序付けしない傾向がある理由は、順序付け要件 (依存関係) でトポロジカルな並べ替えが必要になり、それが高価なアルゴリズムになるためです。
それにもかかわらず、Ocaml GC には、ファイナライザーをオブジェクトにアタッチできる興味深い機能があります。オブジェクトが到達不能になった場合、ファイナライザーが実行されますが、オブジェクトは削除されません (ファイナライザーによって再び到達可能になる可能性があるためです。その場合、別のファイナライザーをアタッチすることもできます)。これらのファイナライザーは、順序付けをある程度制御できます。
于 2011-01-17T13:22:33.057 に答える
0
ウィキペディアから、ガベージコレクターのトレースが最も一般的なタイプであることに注意した後：
ガベージコレクションのトレースは決定論的ではありません。ガベージコレクションの対象となるオブジェクトは、通常、最終的にクリーンアップされますが、いつ（または発生したとしても）それが発生するという保証はありません。
したがって、RAIIに依存すると、リソースの廃棄が遅すぎる可能性があります。
その結果、たとえば、Javaには「ファイナライザーを回避する」ためのガイドラインがあります（Josua Blochによる「EffectiveJava」の項目6）。「ファイナライザーでタイムクリティカルなことをしてはいけません。」
于 2011-01-12T18:15:03.667 に答える
0
ガベージ コレクターは常に実行できるわけではないため (refcounting は近づきますが、通常はガベージ コレクションとしてカウントされません)、試行さえしません。それは明らかに非現実的です。したがって、オブジェクトが到達不能になる (たとえば、唯一の参照が範囲外になるため) と、GC がそれを収集し、場合によってはファイナライザーを起動するまでの間に、必然的に遅延が生じます。この遅延は決定論的ではありません...（そして、最も厳密な意味での決定論的破壊は可能ですが、まだ非現実的ですが）GCを決定論的スケジュールに強制しない限り-しかし、これは「GCが常に実行されている」にかなり近くなります、これはまだ信じられないほど非現実的です。
したがって、GC と決定論的クリーンアップは相互に排他的です。GC がすべてのクリーンアップを行い、決定論的である余裕はなく、その効率を最大化することに頼らなければならないからです。
于 2011-01-12T18:17:31.963 に答える