スコープベースのメモリ管理の欠点

スコープベースのメモリ管理（SBMM）、またはRAIIは、C ++コミュニティでより一般的に（混乱して？）参照されるため、私は本当に気に入っています。私が知る限り、C ++（およびC）を除いて、SBMM / RAIIをメインメモリ管理メカニズムとする他の主流の言語は現在使用されておらず、代わりにガベージコレクション（GC）を使用しています。

これはかなりわかりにくい

1. SBMMはプログラムをより決定的にします（オブジェクトがいつ破壊されるかを正確に知ることができます）。
2. GCを使用する言語では、多くの場合、手動でリソース管理を行う必要があります（たとえば、Javaでファイルを閉じるを参照）。これは、GCの目的を部分的に無効にし、エラーも発生しやすくなります。
3. ヒープメモリは（非常にエレガントに、imo）スコープにバインドすることもできます（std::shared_ptrC ++を参照）。

SBMMがより広く使用されないのはなぜですか？その短所は何ですか？

まず、メモリは他のすべてのリソースを組み合わせた場合よりもはるかに（数十、数百、または数千時間も）一般的であると仮定することから始めましょう。すべての単一の変数、オブジェクト、オブジェクトメンバには、それに割り当てられ、後で解放されるメモリが必要です。開くファイルごとに、数十から数百万のオブジェクトを作成して、ファイルから引き出したデータを保存します。すべてのTCPストリームは、ストリームに書き込まれるために作成された無制限の数の一時バイト文字列と一緒になります。同じページにいますか？すばらしいです。

RAIIが機能するためには（太陽の下ですべてのユースケースに既製のスマートポインターを使用している場合でも）、所有権を取得する必要があります。あなたは誰がいけない、と所有権がAからBに確かに転送する必要があるとき、あなたが共有所有権を使用することができ、これを所有しているか、またはそのオブジェクト必要があります誰が分析する必要があるすべてのものが、その後、あなたはスマートポインタ経由でGCをエミュレートすることと思います。その時点で、GCを言語に組み込むのがはるかに簡単かつ迅速になります。

ガベージコレクションは、最も一般的に使用されるリソースであるメモリに関するこの懸念から解放されます。もちろん、他のリソースについても同じ決定を行う必要がありますが、それらはあまり一般的ではなく（上記参照）、複雑な（共有など）所有権もあまり一般的ではありません。精神的負担が大幅に軽減されます。

ここで、すべての値をガベージコレクションするための欠点をいくつか挙げます。ただし、メモリセーフGC と値型の両方をRAIIと1つの言語に統合するのは非常に難しいので、他の方法でこれらのトレードオフを緩和する方が良いでしょうか？

確定性の喪失は、確定的なオブジェクトの有効期間のみに影響するため、実際にはそれほど悪くないことがわかります。次の段落で説明するように、ほとんどのリソース（メモリは別ですが、メモリは豊富で、かなり遅延してリサイクルできます）は、これらの言語のオブジェクトの有効期間にバインドされていません。他にもいくつかのユースケースがありますが、私の経験ではまれです。

2つ目のポイントである手動リソース管理は、スコープベースのクリーンアップを実行するステートメントで対処されていますが、このクリーンアップをオブジェクトの有効期間に結合しません（したがって、GCおよびメモリの安全性と相互作用しません）。これはusing、C＃、withPython、およびtry最近のJavaバージョンの-with-resourcesにあります。

RAIIは、Perlで使用されているように、自動参照カウントメモリ管理にも準拠しています。参照カウントは実装が簡単で、決定論的で、非常にパフォーマンスが高いですが、循環参照（リークの原因）を処理できないため、一般的に使用されていません。

ガベージコレクション言語は RAIIを直接使用できませんが、多くの場合、同等の効果を持つ構文を提供します。Javaでは、try-with-ressourceステートメントがあります

try (BufferedReader br = new BufferedReader(new FileReader(path))) { ... }

.close()ブロック終了時にリソースを自動的に呼び出します。C＃にはIDisposableインターフェイスがあり.Dispose()、using (...) { ... }ステートメントを離れるときに呼び出すことができます。Pythonには次のwithステートメントがあります。

with open(filename) as f:
    ...

同様に機能します。これに関する興味深いスピンで、Rubyのファイルを開くメソッドはコールバックを取得します。コールバックが実行された後、ファイルは閉じられます。

File.open(name, mode) do |f|
    ...
end

Node.jsも同じ戦略を使用していると思います。

私の意見では、ガベージコレクションの最も説得力のある利点は構成可能性を考慮に入れることです。メモリ管理の正確さは、ガベージコレクション環境のローカルプロパティです。各部分を個別に見て、メモリリークの可能性があるかどうかを判断できます。メモリが正しいパーツをいくつでも組み合わせても、正しいままです。

参照カウントに依存すると、そのプロパティは失われます。アプリケーションがメモリをリークできるかどうかは、参照カウントによってアプリケーション全体のグローバルプロパティになります。パーツ間のすべての新しい相互作用は、間違った所有権を使用してメモリ管理を破る可能性があります。

異なる言語のプログラムの設計に非常に目に見える効果があります。GC言語のプログラムは、相互作用の多いオブジェクトのもう少しスープになる傾向がありますが、GCのない言語では、厳密に制御され制限された相互作用を持つ構造化パーツを好む傾向があります。

クロージャーは、ほとんどすべての現代言語の重要な機能です。それらはGCで実装するのが非常に簡単であり、RAIIで正しく動作するのは非常に難しい（不可能ではありませんが）です。

C ++は、他のすべての人が40年後にそれらを獲得しました。そして、それらを正しくするために、多くの賢い人々による多くのハードワークが必要でした。対照的に、多くのスクリプト言語には、プログラミング言語の設計と実装に関する知識がまったくない人々が設計および実装しています。

1. SBMMはプログラムをより決定的にします（オブジェクトがいつ破壊されるかを正確に知ることができます）。

ほとんどのプログラマにとって、OSは非決定的であり、メモリアロケータは非決定的であり、記述するプログラムのほとんどは並行しており、したがって本質的に非決定的です。大部分のプログラマーにとって、デストラクタがわずかに前または少し後ではなく、スコープの最後に呼び出されるという制約を追加することは、実用上の大きな利点ではありません。

2. GCを使用する言語では、多くの場合、手動でリソース管理を行う必要があります（たとえば、Javaでファイルを閉じるを参照）。これは、GCの目的を部分的に無効にし、エラーも発生しやすくなります。

usingC＃およびuseF＃を参照してください。

3. ヒープメモリは（非常にエレガントに、imo）スコープにバインドすることもできます（C ++のstd :: shared_ptrを参照）。

言い換えると、汎用ソリューションであるヒープを取得し、深刻に制限されている特定のケースでのみ動作するように変更することができます。もちろん、それは事実ですが、役に立ちません。

SBMMがより広く使用されないのはなぜですか？その短所は何ですか？

SBMMは、できることを制限します。

1. SBMMは、ファーストクラスの字句クロージャーで上向きfunarg問題を作成します。これが、クロージャーがC＃のような言語では一般的で使いやすいが、C ++ではまれで扱いにくい理由です。プログラミングでの関数構造の使用に向けた一般的な傾向があることに注意してください。

2. SBMMはデストラクタを必要とし、関数が戻る前に実行する作業を追加することでテールコールを妨げます。テールコールは、拡張可能なステートマシンに役立ち、.NETなどによって提供されます。

3. 一部のデータ構造とアルゴリズムは、SBMMを使用して実装するのが難しいことで有名です。基本的に、サイクルが自然に発生する場所であればどこでも可能です。最も顕著なのは、グラフアルゴリズムです。事実上、独自のGCを書くことになります。

4. ここでは、制御フロー、したがってオブジェクトの有効期間が本質的に非決定的であるため、同時プログラミングはより困難です。メッセージパッシングシステムの実用的な解決策は、メッセージの深いコピーと過度に長い有効期間の使用です。

5. SBMMは、ソースコードのスコープの終わりまでオブジェクトを存続させます。ソースコードは、必要以上に長くなることが多く、必要以上に長くなる可能性があります。これにより、浮遊ガーベッジ（リサイクルを待機している到達不能オブジェクト）の量が増加します。対照的に、ガベージコレクションのトレースは、オブジェクトへの最後の参照が消えた直後にオブジェクトを解放する傾向があります。メモリ管理の神話：promptnessを参照してください。

SBMMは非常に制限されているため、プログラマは、ライフタイムをネストすることができない場合にエスケープルートを必要とします。C ++ shared_ptrでは、エスケープルートを提供しますが、ガベージコレクションのトレースよりも10倍遅くなる可能性があります。したがって、GCの代わりにSBMMを使用すると、ほとんどの場合、ほとんどの人が足を間違えます。ただし、それが役に立たないということではありません。SBMMは、リソースが限られているシステムおよび組み込みプログラミングのコンテキストでは依然として価値があります。

FWIW ForthとAdaをチェックして、Nicolas Wirthの作品を読んでみてください。

TIOBE（もちろん議論の余地はありますが、もちろんこれを使用しても問題ありません）のような人気インデックスを見ると、最初に上位20の〜50％が「スクリプト言語」または「SQL方言」であることがわかります。ここで、「使いやすさ」と抽象化の手段は、決定論的な動作よりもはるかに重要です。残りの「コンパイルされた」言語から、SBMMのある言語の約50％とない言語の約50％があります。したがって、計算からスクリプト言語を除外するとき、私はあなたの仮定が間違っていると思います。コンパイルされた言語の中で、SBMMを使用する言語は、使用しない言語と同じくらい人気があります。

誰も言及していないGCシステムの1つの大きな利点は、GCシステムの参照が存在する限りそのアイデンティティを保持することが保証されるということです。参照のコピーが存在する間にオブジェクトでIDisposable.Dispose（.NET）またはAutoCloseable.Close（Java）を呼び出すと、それらのコピーは同じオブジェクトを引き続き参照します。オブジェクトはもはや何の役にも立ちませんが、使用しようとすると、オブジェクト自体によって予測可能な動作が制御されます。対照的に、C ++では、コードがdeleteオブジェクトを呼び出して後で使用しようとすると、システムの状態全体が完全に未定義になります。

別の重要な注意点は、スコープベースのメモリ管理は、所有権が明確に定義されているオブジェクトに対して非常にうまく機能することです。所有権が定義されていないオブジェクトでは、あまりうまく機能せず、時にはひどくうまく機能しません。一般に、不変オブジェクトには所有者が必要ですが、不変オブジェクトには必要はありませんが、しわがあります。インスタンスを変更する可能性のあるコード。このようなシナリオでは、可変クラスのインスタンスは複数の不変オブジェクト間で共有される可能性があるため、明確な所有権はありません。

まず、RAIIをSBMMと同等にすることを理解することが非常に重要です。またはSBRMにさえ。RAIIの最も重要な（そしてあまり知られていない、または最も評価されていない）品質の1つは、「リソースであること」を構成に推移しないプロパティにするという事実です。

次のブログ投稿では、RAIIのこの重要な側面について説明し、非決定性GCを使用するGCed言語でのリソースの調整とは対照的です。

http://minorfs.wordpress.com/2011/04/29/why-garbage-collection-is-anti-productive/

RAIIは主にC ++で使用されますが、Python（最後に非VMベースのバージョン）にはデストラクタと確定的なGCがあり、RAIIをGCと一緒に使用できることに注意してください。両方の長所があれば最高です。