web-dev-qa-db-ja.com

C ++での例外の動作（舞台裏）

私は、例外が遅いと人々が言うのを見続けますが、証拠は見られません。したがって、例外があるかどうかを尋ねる代わりに、例外が舞台裏でどのように機能するかを尋ねるので、例外を使用するタイミングと遅いかどうかを判断できます。

私が知っていることから、例外は多くのリターンを行うことと同じことですが、リターンの実行を停止する必要がある場合もチェックします。停止するタイミングはどのように確認されますか？私は推測をして、例外のタイプを保持し、そこに到達するまでスタック位置を返す2番目のスタックがあると言っています。また、スタックがタッチであるのは、スローとすべてのトライ/キャッチであると推測しています。 AFAICTがリターンコードを使用して同様の動作を実装すると、同じ時間がかかります。しかし、これはすべて推測なので、知りたいです。

例外は実際にどのように機能しますか？

c++performanceexceptionthrowtry-catch
105
user34537

推測する代わりに、生成されたコードを小さなC++コードと古いLinuxインストールで実際に見ることにしました。

_class MyException
{
public:
    MyException() { }
    ~MyException() { }
};

void my_throwing_function(bool throwit)
{
    if (throwit)
        throw MyException();
}

void another_function();
void log(unsigned count);

void my_catching_function()
{
    log(0);
    try
    {
        log(1);
        another_function();
        log(2);
    }
    catch (const MyException& e)
    {
        log(3);
    }
    log(4);
}
_

_g++ -m32 -W -Wall -O3 -save-temps -c_でコンパイルし、生成されたアセンブリファイルを見ました。

_    .file   "foo.cpp"
    .section    .text._ZN11MyExceptionD1Ev,"axG",@progbits,_ZN11MyExceptionD1Ev,comdat
    .align 2
    .p2align 4,,15
    .weak   _ZN11MyExceptionD1Ev
    .type   _ZN11MyExceptionD1Ev, @function
_ZN11MyExceptionD1Ev:
.LFB7:
    pushl   %ebp
.LCFI0:
    movl    %esp, %ebp
.LCFI1:
    popl    %ebp
    ret
.LFE7:
    .size   _ZN11MyExceptionD1Ev, .-_ZN11MyExceptionD1Ev
_

__ZN11MyExceptionD1Ev_はMyException::~MyException()であるため、コンパイラはデストラクタの非インラインコピーが必要であると判断しました。

_.globl __gxx_personality_v0
.globl _Unwind_Resume
    .text
    .align 2
    .p2align 4,,15
.globl _Z20my_catching_functionv
    .type   _Z20my_catching_functionv, @function
_Z20my_catching_functionv:
.LFB9:
    pushl   %ebp
.LCFI2:
    movl    %esp, %ebp
.LCFI3:
    pushl   %ebx
.LCFI4:
    subl    $20, %esp
.LCFI5:
    movl    $0, (%esp)
.LEHB0:
    call    _Z3logj
.LEHE0:
    movl    $1, (%esp)
.LEHB1:
    call    _Z3logj
    call    _Z16another_functionv
    movl    $2, (%esp)
    call    _Z3logj
.LEHE1:
.L5:
    movl    $4, (%esp)
.LEHB2:
    call    _Z3logj
    addl    $20, %esp
    popl    %ebx
    popl    %ebp
    ret
.L12:
    subl    $1, %edx
    movl    %eax, %ebx
    je  .L16
.L14:
    movl    %ebx, (%esp)
    call    _Unwind_Resume
.LEHE2:
.L16:
.L6:
    movl    %eax, (%esp)
    call    __cxa_begin_catch
    movl    $3, (%esp)
.LEHB3:
    call    _Z3logj
.LEHE3:
    call    __cxa_end_catch
    .p2align 4,,3
    jmp .L5
.L11:
.L8:
    movl    %eax, %ebx
    .p2align 4,,6
    call    __cxa_end_catch
    .p2align 4,,6
    jmp .L14
.LFE9:
    .size   _Z20my_catching_functionv, .-_Z20my_catching_functionv
    .section    .gcc_except_table,"a",@progbits
    .align 4
.LLSDA9:
    .byte   0xff
    .byte   0x0
    .uleb128 .LLSDATT9-.LLSDATTD9
.LLSDATTD9:
    .byte   0x1
    .uleb128 .LLSDACSE9-.LLSDACSB9
.LLSDACSB9:
    .uleb128 .LEHB0-.LFB9
    .uleb128 .LEHE0-.LEHB0
    .uleb128 0x0
    .uleb128 0x0
    .uleb128 .LEHB1-.LFB9
    .uleb128 .LEHE1-.LEHB1
    .uleb128 .L12-.LFB9
    .uleb128 0x1
    .uleb128 .LEHB2-.LFB9
    .uleb128 .LEHE2-.LEHB2
    .uleb128 0x0
    .uleb128 0x0
    .uleb128 .LEHB3-.LFB9
    .uleb128 .LEHE3-.LEHB3
    .uleb128 .L11-.LFB9
    .uleb128 0x0
.LLSDACSE9:
    .byte   0x1
    .byte   0x0
    .align 4
    .long   _ZTI11MyException
.LLSDATT9:
_

驚き！通常のコードパスには、追加の指示は一切ありません。コンパイラーは代わりに、関数の最後にあるテーブルを介して参照される余分な行外修正コードブロックを生成しました（実際には実行可能ファイルの別のセクションに配置されます）。これらのテーブルに基づいて、すべての作業は標準ライブラリによって舞台裏で行われます（__ZTI11MyException_は_typeinfo for MyException_）。

OK、それは実際には私にとって驚きではありませんでした。このコンパイラがどのようにそれを行ったかはすでに知っていました。アセンブリ出力の継続：

_    .text
    .align 2
    .p2align 4,,15
.globl _Z20my_throwing_functionb
    .type   _Z20my_throwing_functionb, @function
_Z20my_throwing_functionb:
.LFB8:
    pushl   %ebp
.LCFI6:
    movl    %esp, %ebp
.LCFI7:
    subl    $24, %esp
.LCFI8:
    cmpb    $0, 8(%ebp)
    jne .L21
    leave
    ret
.L21:
    movl    $1, (%esp)
    call    __cxa_allocate_exception
    movl    $_ZN11MyExceptionD1Ev, 8(%esp)
    movl    $_ZTI11MyException, 4(%esp)
    movl    %eax, (%esp)
    call    __cxa_throw
.LFE8:
    .size   _Z20my_throwing_functionb, .-_Z20my_throwing_functionb
_

ここに、例外をスローするためのコードがあります。例外がスローされる可能性があるという理由だけで余分なオーバーヘッドはありませんでしたが、実際に例外をスローしてキャッチすることには明らかに多くのオーバーヘッドがあります。そのほとんどは___cxa_throw_内に隠されており、次の条件が必要です。

  • 例外のハンドラーが見つかるまで、例外テーブルの助けを借りてスタックを歩いてください。
  • そのハンドラーに到達するまでスタックをほどきます。
  • 実際にハンドラーを呼び出します。

それを単純に値を返すコストと比較すると、例外が例外的なリターンにのみ使用される理由がわかります。

最後に、アセンブリファイルの残りの部分：

_    .weak   _ZTI11MyException
    .section    .rodata._ZTI11MyException,"aG",@progbits,_ZTI11MyException,comdat
    .align 4
    .type   _ZTI11MyException, @object
    .size   _ZTI11MyException, 8
_ZTI11MyException:
    .long   _ZTVN10__cxxabiv117__class_type_infoE+8
    .long   _ZTS11MyException
    .weak   _ZTS11MyException
    .section    .rodata._ZTS11MyException,"aG",@progbits,_ZTS11MyException,comdat
    .type   _ZTS11MyException, @object
    .size   _ZTS11MyException, 14
_ZTS11MyException:
    .string "11MyException"
_

Typeinfoデータ。

_    .section    .eh_frame,"a",@progbits
.Lframe1:
    .long   .LECIE1-.LSCIE1
.LSCIE1:
    .long   0x0
    .byte   0x1
    .string "zPL"
    .uleb128 0x1
    .sleb128 -4
    .byte   0x8
    .uleb128 0x6
    .byte   0x0
    .long   __gxx_personality_v0
    .byte   0x0
    .byte   0xc
    .uleb128 0x4
    .uleb128 0x4
    .byte   0x88
    .uleb128 0x1
    .align 4
.LECIE1:
.LSFDE3:
    .long   .LEFDE3-.LASFDE3
.LASFDE3:
    .long   .LASFDE3-.Lframe1
    .long   .LFB9
    .long   .LFE9-.LFB9
    .uleb128 0x4
    .long   .LLSDA9
    .byte   0x4
    .long   .LCFI2-.LFB9
    .byte   0xe
    .uleb128 0x8
    .byte   0x85
    .uleb128 0x2
    .byte   0x4
    .long   .LCFI3-.LCFI2
    .byte   0xd
    .uleb128 0x5
    .byte   0x4
    .long   .LCFI5-.LCFI3
    .byte   0x83
    .uleb128 0x3
    .align 4
.LEFDE3:
.LSFDE5:
    .long   .LEFDE5-.LASFDE5
.LASFDE5:
    .long   .LASFDE5-.Lframe1
    .long   .LFB8
    .long   .LFE8-.LFB8
    .uleb128 0x4
    .long   0x0
    .byte   0x4
    .long   .LCFI6-.LFB8
    .byte   0xe
    .uleb128 0x8
    .byte   0x85
    .uleb128 0x2
    .byte   0x4
    .long   .LCFI7-.LCFI6
    .byte   0xd
    .uleb128 0x5
    .align 4
.LEFDE5:
    .ident  "GCC: (GNU) 4.1.2 (Ubuntu 4.1.2-0ubuntu4)"
    .section    .note.GNU-stack,"",@progbits
_

さらに多くの例外処理テーブル、およびさまざまな追加情報。

結論として、少なくともLinux上のGCCの場合：コストは、例外がスローされるかどうかにかかわらず（ハンドラーとテーブル用の）追加のスペースに加えて、例外がスローされたときにテーブルを解析してハンドラーを実行するための追加コストです。エラーコードの代わりに例外を使用し、エラーがまれである場合、エラーをテストするオーバーヘッドがなくなるため、fasterになる可能性があります。

より多くの情報が必要な場合、特にすべての___cxa__関数の機能については、元の仕様を参照してください。

104
CesarB

例外が遅い だった 昔はそうだった。
最近のほとんどのコンパイラでは、これは当てはまりません。

注：例外があるからといって、エラーコードも使用しないわけではありません。エラーをローカルで処理できる場合は、エラーコードを使用します。エラーが修正のためにより多くのコンテキストを必要とする場合、例外を使用します：私はここにもっと雄弁にそれを書きました： あなたの例外処理ポリシーを導く原則は何ですか？

例外が使用されていない場合の例外処理コードのコストは実質的にゼロです。

例外がスローされると、いくつかの作業が完了します。
しかし、これをエラーコードを返し、エラーを処理できる場所までさかのぼってチェックするコストと比較する必要があります。どちらも書き込みと保守に時間がかかります。

また、初心者向けの落とし穴が1つあります。
例外オブジェクトは小さいはずですが、中にはたくさんのものを入れる人もいます。次に、例外オブジェクトをコピーするコストがかかります。解決策は2つあります。

  • 例外に余分なものを入れないでください。
  • Const参照によるキャッチ。

私の意見では、例外のある同じコードは、例外のないコードよりも効率的であるか、少なくとも同等であると確信しています（ただし、関数エラーの結果をチェックするためのすべての追加コードがあります）。無料で何も手に入らないことを忘れないでください。コンパイラは、エラーコードをチェックするために最初に記述すべきコードを生成しています（通常、コンパイラは人間よりもはるかに効率的です）。

13
Martin York

例外を実装する方法はいくつかありますが、通常は、OSからの基本的なサポートに依存します。 Windowsでは、これは構造化例外処理メカニズムです。

コードプロジェクトの詳細については、きちんとした議論があります。 C++コンパイラが例外処理を実装する方法

例外がそのスコープ外に伝播する場合、コンパイラは各スタックフレーム（より正確にはスコープ）でどのオブジェクトを破棄する必要があるかを追跡するコードを生成する必要があるため、例外のオーバーヘッドが発生します。関数のデストラクターを呼び出す必要があるローカル変数がスタック上にない場合、例外処理によってパフォーマンスが低下することはありません。

リターンコードを使用すると、一度に1レベルのスタックしか巻き戻すことができませんが、例外処理メカニズムは、中間スタックフレームで何もすることがない場合、1回の操作でスタックをさらに下にジャンプできます。

12
Rob Walker

Matt Pietrekは Win32構造化例外処理 について優れた記事を書きました。この記事は元々1997年に書かれたものですが、今日でも適用されます（もちろんWindowsにのみ適用されます）。

6
Greg Hewgill

この記事 は問題を調査し、例外がスローされない場合のコストはかなり低いものの、実際には例外にはランタイムコストがあることを基本的に発見します。良い記事、推奨。

5
Alastair

私の友人は、Visual C++が数年前に例外を処理する方法を少し書きました。

http://www.xyzw.de/c160.html

2
Nils Pipenbrinck

すべての良い答え。

また、コードが例外をスローするのを許可する代わりに、メソッドの最上部で「ifチェック」を行うコードとしてデバッグする方がどれほど簡単かを考えてください。

私のモットーは、動作するコードを簡単に書くことができるということです。最も重要なことは、それを見る次の人のためにコードを書くことです。場合によっては、9か月であなたのことであり、あなたはあなたの名前を呪いたくありません！

1
Kieveli