たとえば、戻り値のチェックとは対照的に、例外処理に C++ 例外を使用するとオーバーヘッドが発生することを読みました。例外がスローされない場合に発生するオーバーヘッドについてのみ話しています。また、戻り値を実際にチェックして適切な処理を行うコードを実装する必要があると想定しています。また、内部に 45 個の状態変数を持つ例外オブジェクトをスローするコードと、すべてのエラーに対して負の整数を返すコードを比較するのも公平ではありません。
どちらがより速く実行されるかだけに基づいて、C++ 例外の賛成または反対のケースを構築しようとしているわけではありません。最近誰かが、例外を使用するコードは、戻り値をチェックしてエラーを処理するために必要なすべての追加の簿記コードを考慮に入れれば、戻りコードに基づくコードと同じくらい速く実行されるべきであると主張していると聞きました。私は何が欠けていますか？
一部のプラットフォームおよび一部のコンパイラでは、例外処理に関連するコストが発生します。
つまり、Visual Studio は、32 ビット ターゲットをビルドするときに、重要なデストラクタを持つローカル変数を持つすべての関数にハンドラーを登録します。try/finally基本的に、ハンドラーをセットアップします。
64 ビットを対象とする Visual Studioで採用されているもう 1 つの手法では、例外がスローgccされたときにのみオーバーヘッドが発生します(この手法には、呼び出しスタックとテーブル ルックアップのトラバースが含まれます)。例外がめったにスローされない場合は、エラー コードを処理する必要がないため、実際にはより効率的なコードになる可能性があります。
try/catch および try/except ブロックのみ、セットアップにいくつかの指示が必要です。オーバーヘッドは、最もタイトなループを除いて、すべての場合で一般的に無視できるはずです。ただし、内部ループで通常 try/catch/except を使用することはありません。
これについては心配せず、代わりにプロファイラーを使用して、必要に応じてコードを最適化することをお勧めします。
これは完全に実装に依存しますが、最近の多くの実装では、例外がスローされない場合、パフォーマンスのオーバーヘッドがほとんどまたはまったくありません。実際、あなたは正しいです。例外を使用しないコード内のすべての関数からのリターン コードを正しくチェックすると、例外を使用するコードに対して何もしない場合よりも遅くなる可能性があります。
もちろん、特定の要件について確実にパフォーマンスを測定する必要があります。
例外を伴うオーバーヘッドがあります（他の回答が指摘したように）。
しかし、今日では多くの選択肢がありません。プロジェクトで例外を無効にして、すべての依存コードとライブラリをコンパイルして実行できることを確認してください。
例外を無効にして動作しますか?
彼らがそうしていると仮定しましょう！次に、いくつかのケースのベンチマークを行いますが、「例外を無効にする」コンパイル スイッチを設定する必要があることに注意してください。そのスイッチがないと、コードが例外をスローしない場合でも、オーバーヘッドが発生します。
オーバーヘッドのみが、関数の開始時に 2 つの SEH を追加し、最後に残す ~6 命令です。スレッド内の try/catch の数に関係なく、常に同じです。
また、これはローカル変数について何ですか? try/catch を使っていると、いつも文句を言う人がいます。とにかく、デコンストラクターが最終的に呼び出されるため、わかりません。また、例外を 1 ～ 3 回以上呼び出してはいけません。