9

注: オブジェクト ライフタイム RAII を使用しない/ブロック スコープ RAII を使用する

追加の gc カテゴリ、短命のオブジェクト (gc カテゴリをやや頻繁にチェックする)、長命のオブジェクト (gc カテゴリをそれほど頻繁にチェックしない)、およびリソース オブジェクト (gc カテゴリを非常に頻繁にチェックする) を使用することは可能のようです。または、リソース オブジェクトの追加の参照カウント gc を使用することもできます。

using/with スタイルは、I/O のより機能的なスタイル (私が間違っていて、これが機能的なスタイルでない場合は許してください) を促進することで、いくつかの利点があるようです。オブジェクトベースの RAII の柔軟性 (簡単だから)。しかし、問題によっては、リソースの有効期間を追跡するのが難しい場合があります。

gc の複雑さと速度を回避する以外に、これが主流の言語で行われていない理由はありますか?それらの仕様では、一部のタイプのオブジェクト/またはすべてのオブジェクトの参照カウントが指定されておらず、人々が使用する他の実装には参照カウントがなく、それらの言語でのオブジェクトの有効期間 RAII の使用が制限されています。

PS:Perl に C++ タイプの RAII はありますか?

4

1 に答える 1

4

多くの言語では、カスタムの内部ブロック プロセッサ†</sup> を従来の C++ で作成するよりもはるかに簡単に作成できます (これは、最新の標準の現在のドラフトで対処されている可能性があります)。これらがあれば、正確なリソース処理のために RAII を使用するという要件の多くは、差し迫ったものではなくなります。次のようなことができます：

using (Transaction t = makeTX()) {
    // blah
}

それ以外の：

{
    Transaction t = makeTX();
    // blah
}

using複数のネストされた構造がある場合、リソースの解放の順序がより明確になることを除いて、実際には大きな違いはありません。(また、例外がスローされた場合に特別な処理を行う方が IMO の方が簡単で、エラー時にロールバックしたいトランザクションなどに役立ちますが、誰もが私に同意するとは思いません。) また、注意してください。コンストラクトの書き方にはさまざまな方法があり、他の方法usingよりもはるかに重いものもありますが、ここで違いを調べる必要はありません。

正確なリソース処理がこの異なる方法で処理されることを考えると、C++ RAII スタイルの需要ははるかに少なくなり、代わりにガベージ コレクション (GC) を使用することが実行可能です。オブジェクトの有効期間を特定のスコープに結び付けます) はるかに簡単に。公平を期すために、自明ではない有効期間で正確なリソース管理が必要な場合がありますが、そのような場合は誰にとっても厄介です。

Perl はガベージ コレクションを使用し、安価なサブルーチン ブロックを備えています。これは、他のほとんどのスクリプト言語が何らかの形で行うのと同様です (スクリプト言語では、従来のコンパイル済み言語よりもコードとデータの分割が緩いため)。私が知っている GC を使用しない唯一の大きなスクリプト言語は Tcl です。これは、Tcl の値システムが技術的なセマンティック上の理由からループフリーであることが保証されており、参照カウントで十分であるためです。ただし、コードブロックは依然として非常に安価です。

主流のコンパイル済み言語 (つまり、スクリプト言語ではない) を見ると、1990 年頃に実際に分裂が見られます。それ以前の言語 (C++ を含む) は、ガベージ コレクションを想定しない傾向があります (Lisp、Smalltalk、関数型言語などのいくつかの例外を除く)。プログラミング言語) に対して、それ以降の言語 (特に Java と C#)はGC を想定しています。その時点でかなりの哲学的変化があったと思います。おそらく、それ以前の GC で最も深刻な問題に対処するいくつかの巧妙な実装が組み合わされていたのでしょう。GC を使用している場合、RAII をソリューションとは考えていません。これは、C++ の世界モデルに大きく根ざしています。

†</sup> 私はその用語を作りました。

于 2010-10-09T06:54:21.913 に答える