問題タブ [raii]

（元の質問をより意味のあるものに変更しました）

returnステートメントに関して、Raiiオブジェクトはreturnステートメントの前/後/間で破棄されますか？

例えば

ありがとうございました

これは良い習慣ですか？{または、関数と関数の間のコード ブロックを置き換える必要が}ありますか? 再利用できる可能性があります（認めます）が、これを行う唯一の動機は、割り当てられたメモリを解放できるように巨大colsumで必要ないため、割り当てを解除することです。

私は、関数を早期に終了させる可能性のある多くの障害点があるコードのセクションに取り組んでいます。私が操作しているライブラリでは、Cスタイルの配列を関数に渡す必要があります。したがって、すべての出口点で配列に対してdeleteを呼び出す代わりに、次のようにします。

を使用したかったunique_ptrのですが、現在のコンパイラはそれをサポートしておらず、この場合、参照カウントのオーバーヘッドは実際には問題になりません。

レガシーコードとインターフェイスするときに、このプラクティスについて誰かが考えているかどうか疑問に思っています。

UPDATEの代わりにshared_ptr呼び出す ことを完全に忘れました。メモリリークは見られなかったので、それを使用することにしました。ベクトルを使うことすら考えていませんでした。最近、新しい（私にとって）C ++を調べているので、「持っているツールがハンマーだけだと、すべてが釘のように見える」というケースがあると思います。症候群。フィードバックをお寄せいただきありがとうございます。deletedelete []

UPDATE2質問を変更して、同じ間違いを犯した人にとってもう少し価値のあるものにするための回答を提供すると思いました。scoped_array、、などの代替手段がありshared_arrayますvectorが、を使用しshared_ptrて配列のスコープを管理できます（ただし、この後、なぜそうしたいのかわかりません）。

sqlite3接続用に次のクラスを作成しました。

次に、次のように接続を初期化できます

ただし、この接続を共有したり、クラスのメンバーとして保存したりしたいので、デフォルトの代入演算子に問題がありますoperator=。のようなことをする

各変数がスコープ外になると、データベースポインタで2つのsqlite3_close呼び出しが発生します。リソースを別の変数に割り当てる必要がある場合、RAIIでこの問題をどのように克服しますか？

RAIIがリソース管理の最も効率的な方法ではなかった1つ以上の具体的な例を誰かに教えてもらえますか？その理由は何ですか？

スタック上のオブジェクトのスコープを介してスローされた特定の例外のためにスタックが巻き戻されているため、デストラクタが呼び出されているときにデストラクタがいくつかの作業をスキップするようにしたいスタック上のオブジェクトがあります。

これで、スタック アイテムのスコープ内に try catch ブロックを追加し、問題の例外をキャッチして、スキップする作業を実行しないようにスタック オブジェクトに通知し、次のように例外を再スローすることができます。

ただし、これを行うためのよりエレガントな方法があることを願っています。たとえば、次のように想像してください。

「スマート ポインター」として機能し、破棄されたときにある種のシステム リソースを解放するクラスがあるとします。

そして、「リソース」の初期化に使用される値を返す関数がいくつかあります。

今、私のコードでこれを行うと：

AND allocateHandle()が例外をスローすると、正確にはどうなりますか? クラッシュは Resource() の構築中または構築前に発生しますか?

常識的に言えば、allocateHandle が戻る前に例外がスローされるため、実行は Resource() コンストラクターに入るまでもありませんが、正確にはわかりません。これは正しい仮定ですか？

ofstreamオブジェクトのSTLコンテナでRAIIの概念を使用しようとしています。例えば：

ただし、コードと宣言をどのように調整しようとしても、コンパイラーは常に文句を言います。どうやら、ストリーム内にあるstd::basic_iosのコピーコンストラクターはプライベートです。RAIIを使用してこれを行うための簡単なplianC++ / STLソリューションはありますか、または何らかのタイプのスマートポインターを関与させる必要がありますか？

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

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

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

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

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

アイテムを所有するセッションを制御するライブラリへのCAPIを考えると、CAPIをRAIIC ++クラスにカプセル化するための最良の設計は何ですか？

CAPIは次のようになります。

さらに、これらのタイプ（SessionまたはItem）のいずれかに役立ち、関連するオブジェクトのC++メンバー関数に直接マップするその他の関数。ただし、ここでは必要ありません。私の主な関心は、これらのクラスの正しい開閉を管理するためにRAIIを使用して、これらのオブジェクトの構築と破棄にあります。

私のクラスの設計に関する最初のアイデアは、純粋で直接的なRAIIです。含まれているクラスは、コンストラクターパラメーターとしてコンテナオブジェクトを受け入れます。

この設計には、悪い動作を許可するという欠点があります。すべてのItemオブジェクトが破棄される前に、Sessionオブジェクトが破棄される（およびCloseSession関数が呼び出される）可能性があります。それが起こるべきではないので、これは迷惑です。C APIを使用すると、この誤った動作が発生する可能性があり、したがって有効ではない場合でも、C++APIの設計によって回避されるようにしたいと思います。

そのため、セッションにアイテムが含まれ（これは実際の関係を示しています）、アイテムを作成および破棄できる唯一のクラスである次のデザインを使用することを考えています。

アイテムが閉じられる前にセッションが閉じられないようにする唯一の方法は、アイテムオブジェクトがセッションのメンバーであるため、セッションが破棄される前に破棄されることを設計に反映しているように見えます。

ただし、Sessionクラスのインターフェイスにこれらの関数OpenItemとCloseItemが残っているため、私には少し奇妙に見えます。私はRAIIのラインでもっと何かを探していました（私にとって、これはItemのコンストラクターを使用することを意味します）が、正しい破棄順序を保証するカプセル化の方法を想像することはできません。

さらに、ポインタを使用すると、newとdeleteは古すぎるC++です。クラスItemの移動セマンティクスを正しく定義するという代償を払って（Item *の代わりに）Itemのベクトルを使用できるはずですが、初期化されていない2番目のクラスを作成するItemのデフォルトコンストラクターを許可するという代償があります。市民アイテムオブジェクト。

より良いデザインのアイデアはありますか？