問題タブ [exception-safety]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
c++11 - C++ unordered_map 例外の安全性
私は C++ 仕様 (cplusplus.com) をさまよっていましたが、std::unordered_map の例外の安全性について何も語られていないことがわかりました。
だから基本的に私が書くなら
メモリ不足または bad_alloc のために例外がスローされた場合、マップについて何を想定できますか?
- 有効な状態のままですか?(基本保証)
- 変わらずそのまま?(強力な保証)
- 無効な状態のままですか?(保証なし)
c# - 例外セーフでメモリに優しい方法で XML ファイルを作成しますか?
現在のプロジェクトの XML 出力を使用してロガー/バグ トラッカーを作成したいと考えています。重複している場合は申し訳ありませんが、提案は役に立ちませんでしたし、Googleの良い解決策も見つかりませんでした.
1: 私の最初の質問は、例外の安全性についてです。
XmlDocument を使用すると、save を呼び出すまでログがメモリに保存されます。つまり、例外が発生した場合、すべてを失う可能性があります。
XmlWriter を使用する場合、それはメモリに保存されませんが (afaik)、ライターとすべての要素/ノードを閉じる必要があります。これは、例外が発生した場合にも欠落している可能性があります。ライターを閉じて再度開くことはできますか (ドキュメントの最後にポインターを置いて) ?
例外セーフな XML 作成のための最適なソリューションは何ですか? (ヒントだけ欲しい)
2: 2 番目の質問は、メモリ使用量についてです。
これはトレース ツールであるため、出力が非常に大きくなる可能性があります。したがって、XmlDocument を使用できません。私の意見では、XmlWriter がこれに最適なソリューションです。私はこれで正しいですか?
3: 最後の [マイナーな] 質問は、時間の消費についてです。
トレースに XML ファイルを使用することは良い考えですか、それとも悪い考えですか? プログラムの速度はどのくらい遅くなりますか?
あなたが私を助けてくれることを願っています。
編集: なぜ XML を使いたいのですか? 後で、私のアプリは「不明な」環境で実行されるため、インターネット経由でログをサーバーに送信できる必要があり、ファイル (XMLSchema) を検証する必要があります。これが完了したら、それをより読みやすい(そして適切にフォーマットされた)HTMLファイルに変換したいと思います。
ご覧のとおり、これは XML よりもはるかに優れた視覚化です (これにはまだ微調整が必要ですが、機能しています)。
編集 2: 現在の状態 メモリ使用量を測定しました。Logger (現在 XmlDocument :( に基づいています) は、5.000.000 エントリに対して ~600MB 必要です。最高の結果ではありませんが、最悪の結果でもありません。
よろしくアレックス
c++ - ファイルの末尾をデストラクタに書き込む必要がありますか?
次のようなコードがあります。
close 関数はいくつかの xml 終了タグを書き込み、ファイルを適切に解析できるようにします。コンストラクターは、xml ファイルのヘッダーを書き込みます。xmlWriter.close();
クリーンアップコードを検討することができます。C++ では、クリーンアップ コードをデストラクタに入れることが一般的なアドバイスです。これにより、適切にクリーンアップすることを忘れることはありません。ただし、この場合、クリーンアップ コードがスローされる可能性があります。(例外が有効になっている可能性があると想像してくださいfile
。ファイルへの書き込みが失敗する可能性があります。) したがって、close()
関数がデストラクタで呼び出された場合、スローされたすべての例外を食べる try-catch ブロックでラップする必要があります。
ただし、この場合、発信者にはエラーが通知されません。この関数writeToStream()
は、呼び出し元が知らないうちに xml の終了タグをファイルに書き込めない可能性があります。この状況でのベストプラクティスは何ですか?
c++ - デストラクタとキャッチによる失敗処理 (...) { fix(); 投げる; }
例外がスローされたときにクリーンアップが必要なことをしているとしましょう。
たとえば、動的配列を作成していて、オブジェクトを構築する必要があるとしますが、それらのコンストラクターが例外をスローする可能性があります。
次のいずれかで修正できますcatch (...) { ...; throw; }
:
またはスコープ付きデストラクタを介して:
いつ、どの手法を使用するのがよいでしょうか? またその理由は?
(注:この例は、2 つの手法の違いを示すことのみを目的としています。完全なコードではないことはわかっているため、この特定の例に注目しないでください。説明のためだけです。)
c++ - 例外的な安全性:
例外の安全性に関してアドバイスをお願いしたいと思います。特に、私は参照していますDo you (really) write exception safe code? . タイプ のオブジェクトへのポインターのコンテナーがあり、そのオブジェクトのNode
コンテナーをクリアして、オブジェクト_nodes
の新しいコレクションで再初期化する場合、このコードは例外セーフでしょうか?
私はRAIIも読んでいますが、ポリモーフィズムが必要な場所でこれがどのように機能するかわかりません( http://en.wikipedia.org/wiki/Polymorphism_(computer_science)#Subtyping )。
c++ - std::bad_alloc をスローした Qt アプリケーションを強制終了しない方法はありますか?
Modern C++ では、例外の安全性は非常に重要です。
例外の安全性については、すでに素晴らしい質問があります。したがって、一般的な例外の安全性について話しているわけではありません。私は本当に、C++ での Qt の例外安全性について話しているのです。Stack Overflow での Qt 例外の安全性に関する質問もあり、Qt のドキュメントがあります。
Qt での例外の安全性について見つけたすべてを読んだ後、Qt で例外の安全性を達成するのは非常に難しいと感じています。その結果、私は自分で例外をスローするつもりはありません。
本当の問題は std::bad_alloc にあります:
- Qt のドキュメントには、Qt のシグナルスロット接続メカニズムによって呼び出されたスロットからの例外のスローは、スロット内で処理されない限り、未定義の動作と見なされると記載されています。
- 私の知る限り、Qt のどのスロットも std::bad_alloc をスローする可能性があります。
std::bad_alloc がスローされる前にアプリケーションを終了することが唯一の合理的なオプションのように思えます(私は実際には未定義の動作領域に入りたくありません)。
これを実現する方法は、演算子 new and をオーバーロードすることです。
- GUI スレッドで割り当てエラーが発生した場合: アプリケーションを終了 (強制終了) します。
- 別のスレッドで割り当てエラーが発生した場合は、std::bad_alloc をスローするだけです。
その演算子 new を作成する前に、フィードバックをいただければ幸いです。
- それは良い考えですか?
- 私のコードはこの方法で例外セーフになりますか?
- Qt で例外安全なコードを書くことさえ可能ですか?
arrays - make_shared で std::array を初期化する
バックグラウンド
ネットワークプロトコル用のドライバーを作成しており、機能があります。write(std::shared_ptr<package> package)
ここで、(0=>ヘッダー、1=>本体) です。便宜上、ヘッダーを自動生成し、 の最初の形式を呼び出す関数 を書きたいと思います。そのためには を使用したいのですが、呼び出しから を初期化する際に問題があります。package
std::array<buffer_ptr,2>
write(buffer_ptr body)
write
std::make_shared
std::array
make_shared
コード
私が試したもの???
(これらはコンパイルエラーにつながりました)
質問:
これを機能させるための解決策はありますか、それとも次のようなものを書く必要がありますか?
package_ptr package=新しいパッケージ{header, body}; 書き込み (パッケージ);
1.b) に頼らなければならないことで、効率が低下し
package_ptr(new package)
ますか? (メモリ要求を節約するために、ポインタとインスタンスの共有割り当てメモリを1つのチャンクにしたことを覚えています)Cppreferenceでは次のように読み取ります。
さらに、f(shared_ptr(new int(42)), g()) は、g が例外をスローすると、メモリ リークを引き起こす可能性があります。make_shared を使用すると、この問題は発生しません。
メモリがリークするのはなぜですか (が呼び出される前
int(42)
に構築さg
れ、g
呼び出される前に呼び出される可能性がありますshared_ptr
)? そして、1. の代替コードは、そのような潜在的なリークに悩まされるでしょうか?