問題タブ [scopeguard]

Andrei Alexandrescu と Petru Marginean によって何年も前に書かれたこの記事に出くわしました。この記事では、例外セーフ コードを作成するための ScopeGuard と呼ばれるユーティリティ クラスを紹介し、説明しています。これらのオブジェクトを使用したコーディングが本当により良いコードにつながるのか、それともエラー処理を難読化するのかを知りたいのですが、おそらくガードのコールバックは catch ブロックでより適切に提示されるでしょうか? 実際の製品コードでこれらを使用した経験がある人はいますか?

DDJのスコープガード（一般：例外安全コードの記述方法を変更する—永遠に）に関する記事を読みましたが、その一般的な使用法を理解しています。

ただし、一般的な使用法は、特定の操作のためにスタック上の特定のスタックガードをインスタンス化することです。

しかし、実行時にクリーンアップ操作をスケジュールしたい場合、たとえばループがある場合はどうなりますか？

明らかに、forスコープtopSecretとともに閉じられるため、上記の例は機能しません。実行時に必要であると判断したクリーンアップ操作を同じように簡単にキューに入れることができるスコープガードパターンが必要です。このようなものはありますか？

スコープガードオブジェクトを標準キューにプッシュできません。元のオブジェクト（プッシュしているオブジェクト）がプロセスで却下されるためです。ヒープに割り当てられたスタックガードをプッシュし、dtorのメンバーを削除するキューを使用するのはどうですか？誰かがもっと賢いアプローチを持っていますか？

C++標準への準拠またはその欠如について質問があります。

私のプロジェクトでは、const参照トリックを使用するいくつかの単純なGuardクラスを使用しています。Visual Studio 2005を使用していますが、2つの構成があります。1つは通常のリリースビルド用で、もう1つは単体テスト用です。

どちらの場合も、最終的にconst参照に一時的にぶら下がっていますが、その間に何が起こるかが問題です。リリース構成の場合、const参照は、Guardインスタンスを作成するヘルパー関数テンプレートの戻りで作成された一時を直接指します（コピーコンストラクターは呼び出されず、そのことについてはインスタンス化されません）。

ただし、単体テストconfの場合、関数テンプレートtempが最初にコピーされ、次にそのデストラクタが呼び出され、const参照がスコープ外になった後にのみ実行する必要があります。

基本クラスのコピーコンストラクターで元のガードを無効にすることで問題を解決しました（したがって、コピーコンストラクターが呼び出される構成に対してデストラクタのアクションはトリガーされません）が、気になるのは次のとおりです。

一時的なコピーの動作は標準に準拠していますか？標準は、const参照が直接tempを指す必要があることを示していますか、それともこの実装定義の動作は標準で指定されていませんか？

私はコードをDDJのScopeGuardの記事とHerbSutterのgotw88の記事に大まかに基づいていますが、これらのソースはどちらも以前のデストラクタ呼び出しを考慮していないようです。

より知識のある人からの情報をいただければ幸いです。

編集：

コードは次のようなものです。

この記事の参照によるパラメーターのサポートセクションでは、問題を指摘し、参照に対する解決策を提供します。私の質問は、最初にパラメーターを参照として宣言しないのはなぜですか? つまり、代わりに:

行う：

Alexandrescu の概念に基づいた単純な ScopeGuard を作成しようとしていますが、c++ 11 のイディオムを使用しています。

使用法は次のとおりです。

私のバージョンは、そこにあるほとんどの例 (Boost ScopeExit など) よりもはるかに短いため、どの専門分野を省略しているのか疑問に思っています。うまくいけば、私はここで 80/20 のシナリオ (20% のコード行で 80% のきちんとしたコードが得られる) にいると思いますが、何か重要なものが欠けているのではないかと考えずにはいられませんでした。このバージョンの ScopeGuard イディオムの言及

ありがとう！

編集コンストラクターで adquire ラムダを取る makeScopeGuard に関する非常に重要な問題に気付きました。adquire ラムダがスローした場合、スコープ ガードが完全に構築されていないため、 release ラムダは呼び出されません。多くの場合、これは望ましい動作ですが、スローが発生した場合にロールバックを呼び出すバージョンも望ましい場合があると感じています。

完全を期すために、テストを含む完全なコードをここに入れたいと思います:

Resource Acquisition Is Initialization（RAII）イディオムとtry-finallyステートメントは、例外安全プログラミングを作成するための従来のアプローチのバックボーンを形成します。

私の質問は：C＃で利用可能なスコープガードステートメントのようなものはありますか？

リソースを初期化および解放するC関数ペアのRAIIラッパーを作成しましたが、ほとんどの場合に役立ちます。

ただし、関数が戻ってきたときに、このクラスでどのvoidようEnter/LeaveCriticalSectionに実行すればよいかわからないとします。ケースに特化したクラスにする必要がありSuccessValueType = voidますか？または、デフォルトのテンプレートパラメータを使用して何かを行う必要がありますか？

多くの人は間違いなく、Alexandrescus 氏の ScopeGuard テンプレート (現在は Loki の一部) と、ここで紹介されている新しいバージョンの ScopeGuard11 に精通しています: http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012- Andrei-Alexandrescu-Systematic-Error-Handling-in-C

ソースはこちら: https://gist.github.com/KindDragon/4650442

2012 年以降の c++ での講演で、彼は、例外が原因でスコープが終了したかどうかを正しく検出する方法を見つけることができなかったと述べました。したがって、彼は、例外のためにスコープが終了した場合にのみ、提供されたラムダ (通常はロールバック コードに使用される) を実行する SCOPE_FAIL マクロを実装できませんでした。これにより、dismiss() メンバー関数が不要になり、コードが読みやすくなります。

私は Alexandrescu 氏ほど天才でも経験豊富でもないので、SCOPE_FAIL の実装はこれほど簡単ではないと思います。

私の質問は、なぜですか？

関数の戻り値をコピーまたは移動するのは呼び出し元ですか、それとも呼び出し先ですか? たとえば、このようにキューの pop() 関数を実装したい場合

フロント要素をコピーした後にスコープガードのデストラクタが呼び出されますか?

編集:フォローアップの質問: 行は

今すぐ例外安全性を強くしますか?