0

自己完結型のアプリケーション (ライブラリとは対照的に) では、例外の安全性の観点から、目的は「全体にわたって基本的な保証を提供する」ことであると信じるようになりました。

それは合理的に聞こえますか?その目的に貢献する強力で非スローの保証を提供することだけを心配する必要がありますか?

4

2 に答える 2

1

あなたの目的は、可能な限り最強の例外安全性を提供し、それを下げる必要がある場合、または下げないと費用がかかる場合にのみ下げることです。

提供できる最高の例外安全性は nothrow ですが、これを常に回避するのは明らかに困難です。コードがスローする必要がある場所がいくつかあります。それ以外の場合は、一般的に例外を回避しているだけです。

次に、強力な保証を目指して努力する必要がありますが、これは実装に費用がかかる可能性があります。多くの場合、関数の操作中に監視可能な状態が影響を受けないようにするために、過剰な一時コピーを作成する必要があります。

少なくとも、基本的な保証を提供する必要があります。漏れがないことを確認しているだけなので、通常、これを確認するのに費用はかかりません。スマート ポインター型は、そのために役立ちます。それは基本的な保証が悪いという意味ではありませんが、もっとうまくやれるならそうすべきです.

おそらく、その目的は、「少なくとも基本的な保証を提供するが、得ることができる最高の保証を目指して努力する」と書いたほうがよいでしょう。

于 2013-01-27T14:04:53.737 に答える
0

この質問は、アプリケーションを書いている人が最もよく答えると思います。exit() を呼び出して失敗を通知するコードがありますが、これはかなりの数のガイドラインに違反していますが、その特定のケース (コンパイラのようなワンショット アプリケーション) ではその決定を正当化できると思います。実際には、リソースをクリーンアップすることさえせず、それを OS に任せます。一方、スタンドアロン アプリケーションが長寿命のサーバー アプリである場合、基本的な保証だけでは十分ではありません。さらに、ライブラリ コードについては、通常、それがどこで使用されているかを判断するために必要な知識を持っていないため、注意が必要です。

要約すると、ガイドラインとして強力な/nothrow 保証を提供するように努めるべきだと思いますが、特定のケースではこれらの要件を下げる (できれば十分な情報に基づいた) 決定を下すことができます。

于 2013-01-27T16:26:31.990 に答える