問題タブ [exception-safety]

次のクラスの例では、getter メソッドの例外安全性の保証は何ですか?

そのようなゲッターメソッドは、最低限の強力な保証を提供しますか?

基本型を値で返すと、常にノースロー保証が提供されますか?

まず、Objective C プログラミングに関する知識が非常に限られていることをお伝えします。

Objective C で記述されたユーザー定義関数を呼び出す C 実行可能ファイルがあります。

ユーザー コードで何かが発生する可能性がある場合、C 関数が正常に戻るようにコードを安全にラップする最善の方法は何でしょうか?

C++ ラッパーでは、C++ 例外が C 標準で定義されていない C コードに伝播するのを防ぐために、すべての例外を try キャッチする関数を記述します。

ObjC の例外が言語の境界を越える (つまり、C コードに伝播する) ことを最初に防止する必要があると思います。そのため、次のようなラッパーを記述します。

ただし、言語に関する私の限られた知識では、ユーザー コードがモジュールの境界を越えて未定義の例外を引き起こすメカニズムが他にあるかどうかはわかりません。

さらに、エントリ ポイントが純粋な C である場合、ユーザー関数を呼び出す前に Objective C ランタイムの初期化/クリーンアップが必要ですか?

注: ラッパーはフォークされたプロセスで実行されるため、シグナルと exit() を処理する必要はありません。

Python3 スクリプトがあり、必要に応じてファイルにリダイレクトstdoutしたいと考えstderrています。このようなもの：

途中の私のコードが終了することを決定しない限り、これは機能します。次に、ファイルが閉じていることが保証されていません。コードで何が起こっても、これらのファイルをきれいに閉じるにはどうすればよいですか? （通常、シェル経由でリダイレクトしますが、Pythonでファイル名を計算していて、さまざまなシェルで再計算したくありません。また、リダイレクトするかどうかのロジックを入れたくありませんシェルスクリプトで. 可能であれば、メインコードにそれらのブランチが必要です.)

試行 1

コンテキストマネージャーがここまでの道のりのようですが、それらを使用しようとすると、コードを何度も書き直す必要があり、きれいなコードではありません。

試行 2

そのためのコンテキストマネージャーを作成することにしました。私はそれがうまくいくと思うし、Python は私に怒鳴っていない. 私はif声明を奇妙な方向に押し進めています。より良い方法はありますか？

の項目 17 にexceptional c++、次のようなものがあります。

まず、すべてのコンテナーについて、複数要素の挿入 (「イテレーター範囲」の挿入) は決して強力な例外セーフではありません。

の項目 1 にeffective STL、次のようなものがあります。

複数要素の挿入にトランザクション セマンティクスが必要な場合 (たとえば、範囲形式 — 項目 5 を参照)、リストを選択する必要があります。リストは、複数要素の挿入にトランザクション セマンティクスを提供する唯一の標準コンテナーだからです。

のページ249でthe c++ standard library 2th、これを見つけました：

リストの場合、複数要素の挿入操作でもトランザクション セーフです。

だから私の質問は、どちらが正しいですか？強く例外的に安全な手段は、トランザクションセーフと同じですか?

私は最近、カスタム シリアル通信プロトコルのコードを書いていました。私がしたことは、受信データの一部 (8/16 ビット) を使用して、フレーム サイズの大きさを示すことでした。このデータに基づいて、次のデータはないと予想しています。Crc を使用してフレームを承認または拒否します。しかし、受信側では、フレームを処理する前に、予想されるデータ量を知る必要があるため、Crc にフレーム長データを含めることはできません。

私が直面した問題は、このフレーム長のデータが破損し、受信側の配列サイズがそれよりもはるかに小さいのに対し、受信側がそのバイト数を受信するようにだますことです。これにより、連続したメモリ位置に存在する多くの重要なシステム変数が破損します。

バッファ オーバーフローが発生しないようにするにはどうすればよいですか? これに関する私の考え 1) フレーム長データが特定の値を超えた場合は拒否します。2) 最大数を制限するデータ型を使用します。配列インデックスの範囲を 256 のメモリ ロケーションに制限する short を使用するように、280 バイトのバッファを作成します。3) メモリを別の場所に割り当てて、重要なシステム変数に影響を与えないようにします。

受信ループに陥るのを防ぐために使用したことの 1 つは、タイムアウトを使用することです。しかし、私はこの問題のこの側面を見落としていました。コードはより大きなシステムコードの一部であり、私はここの専門家ではないため、問題を確認して再現する時間があれば、私にはよく見えます。

一般的に、この種の問題を安全に処理するにはどうすればよいですか?

また、オーバーフローを防ぐために、配列を使用する際に従うべき一般的な考慮事項または標準的な慣行は何ですか?

いくつかの実装中に、例外の安全性の保証と使用に関する問題に固執しましたstd::move()。SOは「あなたの意見は何ですか」（クラステンプレートBoo）のような質問をするのに適した場所ではないことを知っていますが、ここで私の理解が正しいかどうかを確認したいと思います。この質問を読んだ後、私に指示してください正しい道。

次のコードを検討してください。

add()(1) から例外がスローされ、n4296 [vector.modifiers/1] に従って、メンバー関数を見てください。

TisCopyInsertableまたはis_nothrow_move_constructible<T>::valueisの末尾に単一の要素を挿入しているときに例外がスローされた場合、true影響はありません。

強い保証が保たれますよね？

（2）を見ると、（3）が例外をスローできるため、ここでも例外がスローされる可能性があります。私が間違っている場合は修正してください: この状況で (2) メンバー関数に移動srcし、process()そこから例外がスローされたprocess()場合srcは指定されておらず、基本的な保証のみが保持されることを意味しますか?

メンバー関数をadd()強力に保証するには、(2) と (F) をそれぞれ次のように変更する必要があります。

?

したがって、Foo::src膨大な数の要素がある場合、強力な保証を行うと効率が低下します (余分なコピーを作成する必要があるため) ?

保証レベルは、次のようにクラス テンプレートにすることで、クラスのユーザーが決定できるようにする必要があります。

それは良い考えですか、それとも悪い考えですか？