タグ付けされた質問 「raii」

8
スコープベースのメモリ管理の欠点
スコープベースのメモリ管理(SBMM)、またはRAIIは、C ++コミュニティでより一般的に(混乱して?)参照されるため、私は本当に気に入っています。私が知る限り、C ++(およびC)を除いて、SBMM / RAIIをメインメモリ管理メカニズムとする他の主流の言語は現在使用されておらず、代わりにガベージコレクション(GC)を使用しています。 これはかなりわかりにくい SBMMはプログラムをより決定的にします(オブジェクトがいつ破壊されるかを正確に知ることができます)。 GCを使用する言語では、多くの場合、手動でリソース管理を行う必要があります(たとえば、Javaでファイルを閉じるを参照)。これは、GCの目的を部分的に無効にし、エラーも発生しやすくなります。 ヒープメモリは(非常にエレガントに、imo)スコープにバインドすることもできます(std::shared_ptrC ++を参照)。 SBMMがより広く使用されないのはなぜですか?その短所は何ですか?

5
Java / C#でRAIIを実装できないのはなぜですか?
質問:Java / C#でRAIIを実装できないのはなぜですか? 明確化:ガベージコレクターは決定論的ではないことを認識しています。そのため、現在の言語機能では、オブジェクトのDispose()メソッドをスコープの終了時に自動的に呼び出すことはできません。しかし、そのような決定論的な機能を追加できますか? 私の理解: RAIIの実装は、次の2つの要件を満たす必要があると感じてい ます。1.リソースの有効期間はスコープにバインドされている必要があります。 2.暗黙的。リソースの解放は、プログラマーによる明示的なステートメントなしで行われる必要があります。明示的なステートメントなしでメモリを解放するガベージコレクターに似ています。「暗黙性」は、クラスの使用ポイントでのみ発生する必要があります。もちろん、クラスライブラリの作成者は、デストラクタまたはDispose()メソッドを明示的に実装する必要があります。 Java / C#はポイント1を満たします。C#では、IDisposableを実装するリソースを「using」スコープにバインドできます。 void test() { using(Resource r = new Resource()) { r.foo(); }//resource released on scope exit } これはポイント2を満たしません。プログラマは、オブジェクトを特別な「使用」スコープに明示的に結び付けなければなりません。プログラマーは、リソースをスコープに明示的に結び付けることを忘れる可能性があり(実際にそうします)、リークを作成します。 実際、「使用中」ブロックは、コンパイラーによってtry-finally-dispose()コードに変換されます。try-finally-dispose()パターンと同じ明示的な性質を持っています。暗黙のリリースがなければ、スコープへのフックは構文糖衣です。 void test() { //Programmer forgot (or was not aware of the need) to explicitly //bind Resource to a scope. Resource r …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.