問題タブ [exception-safe]

このプロパティやその他の関連プロパティに使用される用語を思い出せません。

編集-そのような概念は存在しないかもしれませんが、ベクトルスワップ関数は例外をスローしないことが保証されているため、スワップを使用して関数の最後に変更をコミットすることを提唱したEffective C ++（またはより効果的なC ++）で何かを読んだことを覚えています。

HtmlTextWriterHTMLを生成するために.Netを使用しています。

この例では、実行中にエラー例外がmyObject.GenerateHtml()発生した場合、素敵なエラー html を生成しますが、その前にspan決して閉じられない開始タグが表示されます。

私はそれをそのようにリファクタリングすることができました

大変な作業が終わるまでスパンは開きませんが、これは私にはぎこちなく見えます。HtmlWriter でロールバックする方法はありますか? ブロックを使用する負荷を入れなければならなかったとしても。

私は現在 .Net 2.0 で作業していますが、3.5 での解決策についての議論は問題ありません。

ポインターをパラメーターとして受け入れる関数があるとします。この関数はstd::vector<>::push_back()、このポインターのライフサイクルを管理するために使用するため、例外をスローできます。次のように宣言すると:

次のように呼び出します。

ポインタを にプッシュする例外がスローされた場合std::vector<>、事実上メモリリークが発生していますよね？

次のように関数を宣言します。

私の問題を解決しますか？

std::auto_ptr最初にスタックに割り当てて（例外をスローすることはできなかったと思います）、ポインターに対する所有権を取得できるようにすることを期待しています。安全。

次に、関数内で生のポインターを にプッシュしますがstd::vector<>、これも安全です。これが失敗した場合、ポインターは追加されませんが、スマート ポインターは引き続きポインターを所有しているため、破棄されます。プッシュが成功した場合、そのポインターに対するスマート ポインターの所有権を削除して戻ります。これは例外をスローできないため、常に問題ありません。

私の理論は正しいですか？

- 編集 -

いいえ、できないと思います。これを行うには、rvalue への非 const 参照を取得する必要があります (スマート ポインターから所有権を奪うため)。私は書かなければならないだろう

それが機能するためには、私の場合はかなり不便です。これを書いているのは、コードをあまり汚さずに RAII を実装できるようにするためです。そんなことをしても何の役にも立ちません。キャッチ22になります。

-- 編集 2 --

読者がすぐに参照できるように、ジェイソン・オレンドルフがここに言ったことをここに引っ張り出すと、最終的な解決策は次のようになります。

これにより、右辺値への無用な非 const 参照の問題が解決されます。

コーディング中のこのクラスを終了したら、誰かが役に立つと思った場合に備えて、ここに投稿します。

-- 編集 3 --

わかりました、ここで多くの議論がありましたが、以前に明確にしておくべき重要なポイントがあります。通常、stackoverflow に投稿するときは、質問の背後にある理由を説明しようとしますが、一般的に、それはまったく役に立ちません。ということで、今回は本題に入ろうと思いました。うまくいかなかったことが判明 XD

残念ながら、私の脳は今行き詰まっているので、目標を達成するために最初に考えたことを正しく説明することさえできないと思います. 多くの場合に適合するアトミック操作と例外セーフなコード作成の適切な解決策を見つけようとしていますが、実際にはそれを処理できません XD これは時間とともに習得するだけの種類のものだと思います.

私はまったく新しい C++ プログラマーで、ゲーム開発に重点を置いています。ゲームエンジンで例外がスローされると、それは実行の終了です。システムはプロセス用にすべてのメモリを解放するので、あちこちで 1 つまたは 2 つのポインターがリークしても問題ありません。サーバー アプリケーションを開発しているので、例外を処理するのが難しいと感じています。例外はサーバーをクラッシュさせることはできないからです。「リクエストをクラッシュさせる」必要があります。

つまり、「お客様、残念ながら開発者はこの状態を予測していませんでしたので、後で試していただく必要があります (ここまでは基本的にゲーム エンジンと同じで、何も修復されていないだけです。プロセス全体ではなく、リクエストのみのコンテキストに分離されます。ただし、すべてが有効な状態のままであるため、パニックにならないでください (ただし、ここに違いの 1 つがあります。プロセスは終了しないため、オペレーティング システムはリソースを解放できません。さらに、これまでの操作を元に戻すには注意が必要です。たとえば、ユーザーのアカウントを完全にロックしたり、サーバーが提供する完全なサービスをロックしたりしないようにする必要があります。 ）」。

次回はより良い質問を書くことができるように、どんどんコーディングして問題を書き留めます。今さら質問する気になれませんでした、本当に申し訳ありません。

返信ありがとうございます。私はスタックオーバーフローが本当に好きです。私の質問に対する回答の速さと、あなたの回答がどれだけ啓発的であるかには、本当に驚くべきものがあります。ありがとう。

理由が値を返さないという質問への回答で、例外安全性の理由（コピーコンストラクターがスローした場合はどうなりますか）が原因であるstd::stack::pop() と主張しました。pop

@Konradは、moveセマンティクスでは、これはもはや関係がないとコメントしました。これは本当ですか？

AFAIK、moveコンストラクターは可能 throwですが、おそらくnoexceptそれを使用しても達成できます。

ボーナスポイントについては、この操作でどのスレッドセーフが保証されますか？

編集:私は言及すべきでした.Boostのドキュメントをptr_sequence_adapter見ていましたが、それらのアダプターtemplate< class U > void push_back( ::std::auto_ptr<U> x );は実行と同等でvec.push_back(autoPtr.release());あり、強力な例外保証も提供すると主張しています. そして、実装が実際に何であったかについて、実装の効果に関する彼らの説明を混同していることに気付きました。したがって、この質問はほとんど無意味です。後世のためにここに残しておきます。

私には、への呼び出しstd::auto_ptr<t>が成功し、への呼び出しがstd::vector<t*>::push_back例外をスローし、ポインターがリークする可能性があるようです。

代わりにこれを行う必要があるようです：

動的に割り当てられたオブジェクトをベクターに追加する必要があるときはいつでも、次の方法でそれを行ってきました。

それはうまくいっただけで、他の多くの人も同じことをしているようです。

今日、vector::push_back が例外をスローできることを学びました。つまり、上記のコードは例外セーフではありません。:-(だから私は解決策を思いついた：

しかし、問題は、新しい方法が冗長で退屈であり、誰もそれを行っていないことです。（少なくとも私の周りでは…）

私は新しい道を歩むべきですか？
それとも、昔のやり方のままでいられますか？
または、それを行うより良い方法はありますか？

私は、少なくとも最良のシナリオ以上のプログラムを作成しようとする駆け出しのプログラマーです。私は Herb Sutter の「Exceptional C++」を読んでおり、これまでに例外安全性の章を 3 回読みました。ただし、彼が提示した例 (スタック) を除いて、例外の安全性と速度を正確に比較する必要がある時期と、そうするのがばかげている時期はよくわかりません。

たとえば、私の現在の宿題プロジェクトは二重リンク リストです。すでにこれらのいくつかをプログラムしたので、時間をかけて ES などのより深い概念に取り掛かりたいと思いました。

これが私のポップフロント機能です：

これにはいくつかのジレンマがありました。

1) リストが失敗した場合、本当にエラーをスローする必要がありますか? リストのユーザーに try {] catch() {} ステートメント (これも遅い) を強制的に実行させるのではなく、単純に何もせずに戻るべきではないでしょうか。

2) 複数のエラー クラスがあります (さらに、クラスに実装することを先生が要求する ListException もあります)。カスタムエラークラスは本当に必要ですか?特定の例外クラスをいつ使用するかについての一般的なガイドはありますか? (たとえば、範囲、長さ、境界はすべて同じように聞こえます)

3) 例外をスローしたすべてのコードが完了するまで、プログラムの状態を変更してはならないことを知っています。これが、size_last をデクリメントしている理由です。この単純な例では、これは本当に必要ですか? delete がスローできないことはわかっています。0 に割り当てたときに head_->prev がスローされることはありますか? (頭は最初のノードです)

私の push_back 関数:

1) C++ プログラムでは何でも失敗する可能性があるとよく耳にします。ListElem のコンストラクターが失敗するかどうか (または ing 中に tail_ が失敗newするかどうか) をテストするのは現実的ですか?

2) 型が構造に対して実行可能であることを確認するために、データの型をテストする必要がありますか (現在、typedef int Tすべてをテンプレート化するまでは単純です)。

これらは非常に単純な例であることは理解していますが、実際に優れた ES を実践する必要がある場合とそうでない場合について、現在混乱しています。

このアプローチは安全ではありませんか？

それとも、オブジェクトcreateFooを返すことが望ましいでしょうか？shared_ptr<Foo>

次のようなコードがあるとします。

ここで特定の言語について言及しているわけではありませんが、Java、C#、および C++ が良い例になると思います ( MSVC++ で__try/を使用していると仮定します)。__finally

これは例外セーフですか?

個人的には、これは例外セーフではないと思います。ブロックに入る前に例外が発生した場合はどうなるでしょうか? tryその後、リソースがリークします。

しかし、私はこれを十分に見てきましたが、何かが欠けていると思います... 私は? それとも、これは本当に危険ですか？

編集：

例外をスローすることについて質問しているわけではありませんが、その関数が返された後、割り当てられる前にallocateResource例外が発生する状況です。 resource

Exception Safety Guarateesについて説明し、 Strong Guaranteeを提供すると思われる例を考案しました。

簡単な (C++0x)-これがどのように使用されるかの例:

LT要素を変更しないと仮定しますが、スローされる可能性があります。コードが提供するものであると仮定するのは正しいですか

• 強力な例外安全保証
• Exception Neutralであり、 wrt toLT