👩🏾‍🎓 📀 👨‍🎓 C ++例外の処理で難しいのは何ですか？ 👩‍🎤 👷🏼 🐓

例外と関連するスタックプロモーションは、C ++で最も優れた手法の1つです。例外処理は、プログラムのブロック構造と直感的に一貫しています。外部的には、例外処理は非常に論理的で自然なようです。

スタックオブジェクトを正確に使用すると、非常に効率的で安全なコードを作成できます。ガベージコレクションを使用するシステムとは異なり、リンクの局所性が維持されるため、メモリに対するシステムの呼び出し回数を減らし、断片化を減らし、メモリキャッシュをより効率的に使用できます。

ただし、C ++では、例外は従来、文字通りエラー回復に関連する例外と見なされます。これが、コンパイラによる例外処理の実装が非常に高価であるという理由または結果であるかどうかを言うのは困難です。理由を理解してみましょう。

ここに続きます。
状況はどうですか。

例外処理を実装するには、2つのアプローチがあります。

1つ目は、「敗者に支払いをさせる」という言葉で説明できます。コンパイラーは、例外が発生しない場合のコストを最小化しようとします。理想的には、プログラムには追加の負荷がかからず、必要な情報はすべて、プロモーションに便利な形式でコードから離れた場所に配置されます。
2番目の戦略は「誰もが多く常に支払う」ことです。つまり、プロセスにおいて、プログラムはスタックの正しいプロモーションに必要な情報の関連性を維持するために特定のコストを負担します。さらに、例外の場合、スタックのプロモーションは安価です。

いくつかの例：

GCC / SJLJ SJLJはsetjmp / longjmpの略です。むしろ、最初のアプローチを指しますが、コントロール転送スキームのおかげで、試行ごとに固定料金もかかります。本質的に、この実装には、両方のアプローチに固有のすべての最悪が組み込まれています。 4番目のバージョンまで、これは主要な例外処理オプションでした。
名前が示すように、制御の転送はlongjmpの呼び出しを介して実行され、各試行はsetjmpの呼び出しを生成します。対応するバッファは、各tryブロックのスタックに割り当てられます。
各関数の最初に、現在のフレームをコンテキストスタックに登録するプロローグが作成されます。同様に、現在のコンテキストをコンテキストスタックの最上部から削除するエピローグが作成されます。リソースをクリアするために、各関数の隣にヘルパーコードが作成されます。
より正確には、コンパイラーは、例外として終了する可能性のある関数からの戻りをキーとしてツリーに記録します。値はクリーニングコードへのポインターであり、関数のコンテキストをクリアするにはこの場所で取得する必要があります。リンカは、各リンクモジュールのこれらのツリーの断片を単一のプロジェクトツリーに収集します（非常に大雑把です）。この奇跡はLSDA（言語固有のデータ領域）と呼ばれ、「。gcc_except_table」セクションにあります。
スローされた例外のtype_infoに基づいて例外が発生した場合、この例外を処理できるブロックが検索されます。現在のコンテキストからハンドラコンテキストまで（呼び出しフレームのナビゲーションを使用）、コードのアドレスが抽出されて実行されます（ローカル変数のスコープに応じて）この場所で実行する必要があります。次に、制御が転送されます。

この方法は非常に高価であるという先入観があります。すでに、すべてのtryブロックに対してsetjmpが呼び出されているという事実によりますが、これは安くはありません。実際、プロセッサの状態を完全に維持する必要があります。この場合、数十個のレジスタが存在する可能性があります。一方、例外の時点では、これらのレジスタのほとんどの内容はすでに役に立たない。実際には、コンパイラは非常に合理的に機能します。彼はsetjmpをデプロイし、有用なレジスターのみを保存します（すでにこの情報を持っています）。著者は、setjmpのコストが非常に高いことを疑っています。

しかし、本当に目を引くのは、特に重要な場合に、膨大な補助コードです。コンパイラは、YACCと同様に、スタックマシンのすべての状態をペイントします。そして、可能であれば、オプティマイザーは冗長性と簡単なコードをクリーンアップしますが、残っているのは十分以上です。
GCC / DW2 これは、例外処理の最初のアプローチの例にすぎません。 DW2は、DWARF2（現在3つ既に）-実行可能ファイル内のデバッグ情報を含む、補助情報を格納するための形式を意味します。結局、デバッグ情報も必要であるため、以前の（上位の）呼び出しのフレーム内を含め、変数の値をいつでも見つけることができます。したがって、コード生成のプロセスでは、コンパイラーは、変数を格納するときに、変数を配置するスタックに割り当てるものに関する情報を延期します...実際、この形式はDWARFと非常に似ていますが、DWARFと同一ではありません。 GCCの4番目のバージョンの標準。

概念的には、呼び出しの上位フレームに入る方法に関する情報は、プログラムコードの各アドレスに格納されます。実際には、この情報の量が多いため、圧縮されます。実際、バイトコードの解釈を使用して計算されます。このバイトコードは、例外が発生したときに実行されます。これらはすべて「.eh_frame」および「.eh_frame_hdr」セクションにあります。
はい、とりわけ、DWARFインタープリターは優れたバックドアであり、その助けにより、バイトコードを変更することで、例外をキャッチし、どこにでも処理のために送信できます。
GCC / DW2は、GCC / SJLJとほぼ同じLSDAセクションを使用します。

ご覧のとおり、スタックプロモーションに関連するコスト（例外がない場合）は実質的にありません。ただし、例外を発生させるコストは高くなります。さらに、コンパイラーのアーキテクチャー依存部分とそのかなり高レベルのレイヤーの強力な統合に注意することは間違いありません。
MS VC ++ 。このコンパイラは、2番目の処理戦略を実装しています。
- 潜在的に例外をスローする可能性のある各関数に対して、コンパイラーは、スタック変数として、以前の類似構造へのポインターからの構造、ハンドラー関数のアドレス、および補助データを作成します。この構造のアドレスはFSに入力されます：[0]。これらの構造のスタックの最上部です。 Win32のFSレジスタは、スレッド情報ブロック（ TIB ）（Win64のGS）として使用されます。また、ハンドラー関数（独自のデータセットを使用）と、FSを復元するエピローグも作成します：[0]成功した場合。
- コンパイラーは、関数内の各tryブロックの要素ごとに構造のテーブルを作成します。各tryブロックには、特定の状態に対応するこのテーブルの開始インデックスと終了インデックスがあり（ネストされたブロックにはネストされた間隔があります）、コンパイラ自体がこのインデックスの関連性を監視します。このようにして、コンパイラーはtryブロックのスタックを実装します。
- 各try-blockについて、catch-blockテーブルが開始されます。例外のタイプごとに、このタイプの例外の階層内のすべての基本クラスに対してtype_infoテーブルが作成されます。
- 関数ごとにアンワインドテーブルが作成され、その各要素には、一部のリソースと前の要素の数を解放する関数へのポインタが含まれます。デストラクタを持つオブジェクトのスコープに応じて、テーブルにはいくつかのチェーンがあります。例外の時点で、上記の現在の状態のインデックスによって、必要なチェーンを見つけて、必要なすべてのデストラクタを呼び出すことができます。
- バージョンx64では、可能であれば、補助スタック構造が.pdataに転送されました;おそらく、MSは最初の戦略がより有望であると考えています。
- 例外がスローされると、主な作業はオペレーティングシステムによって実行され、SYSENTERを介して制御が取得されます。
このメソッドには、SJLJと同じ欠点があります-広範なヘルパーコードと低い移植性。
例外を発生させ、どこでも適切なcatchブロックを選択するプロセスは、ほぼ同じように見えます。
- 例外がスローされると、オブジェクトのコピー、type_info、デストラクタへのポインタを含む記述子が作成されます
- tryブロックのスタックに沿って上昇し、登録されているすべてのスタックオブジェクトをクリアします（このスタックのナビゲーションはどこでも異なりますが、本質は同じです） 。catchブロックのリストを調べて、適切なものを探します。
- 適切なcatchブロックが見つかった場合、例外オブジェクトはローカル変数になります;このブロックを呼び出します。 catchブロックが参照ではなく値による例外を受け取る場合、そのコピーが作成されます。
- 例外の再呼び出しがなかった場合、オブジェクトを強制終了します-例外
- 「メモへの愛人」：
```
some_exception exc("oioi"); throw exc; 
```
  余分なコピーコンストラクタ/デストラクタを生成します
```
 throw *new some_exception("oioi"); 
```
  メモリリークが発生します
```
 catch(some_exception exc) ... 
```
  コンストラクタとデストラクタの追加呼び出し
```
 catch(const some_exception *exc) ... 
```
  ポインタをドロップしない限り、例外が飛びます
```
 throw some_exception("oioi"); ... catch (const some_exception &exc).... 
```
  最低費用

詳細はこちら、こちら、こちらをご覧ください。

もしも...
そして、それはすべてであり、そうすることのように思えます-死体がすでに存在するデストラクタを正しい順序で呼び出すことです。単純で一般的なタスクに、粘性があり、重く、さらには独自に開発されたソリューションがあるのはどうしてですか？言うのは難しいので、歴史的に。
ソリューションを簡単に説明し、可能な場合はアーキテクチャに依存しないようにします。

まず、戦略を選択します-これが2番目のオプションになります。
コントロール転送-setjmp / longjmp
構造体を作成します。その子孫はすべて、可能な昇進に自己登録することができます。
```
 struct unw_item_t { unw_item_t (); virtual ~unw_item_t (); void unreg(); unw_item_t *prev_; }; 
```

そしてもう1つ、スコープはtryブロックです

 struct jmp_buf_splice { jmp_buf_splice (); ~jmp_buf_splice (); jmp_buf buf_; jmp_buf_splice *prev_; unw_item_t objs_; };

簡単にするために、const char *例外のみをスローします。
```
  extern int throw_slice (const char *str); 
```

tryブロックをシミュレートするためのいくつかのマクロ

 //   #define TRY_BLOCK { \ jmp_buf_splice __sl; \ const char *__exc = (const char *)setjmp (__sl.buf_); \ if (NULL == __exc) { ... // -  catch(…) ..    const char* #define CATCH_BLOCK_FIN \ } else { ... //   #define FIN_BLOCK \ } \ } ... //   #define THROW_IN_BLOCK(exc) \ throw_slice (exc); ... //   , __exc   TRY_BLOCK #define RETHROW_IN_BLOCK \ throw_slice (__exc);

jmp_buf_spliceクラスのメンバーのボディを表示します。
```
 static jmp_buf_splice *root_slice_ = NULL; jmp_buf_splice::jmp_buf_splice () { objs_ = NULL; prev_ = root_slice_; root_slice_ = this; } jmp_buf_splice::~jmp_buf_splice () { root_slice_ = prev_; } 
```
シングルスレッド実装のオプションは次のとおりです。複数のスレッドがある場合、root_slice_の代わりに、たとえばGCCが行う方法と同様に、TLSを使用する必要があります。

unw_item_tクラスのメンバーの時が来ました：

 unw_item_t::unw_item_t () { if (NULL != root_slice_) { prev_ = root_slice_->objs_; root_slice_->objs_ = this; } } unw_item_t::~unw_item_t () { unreg(); } unw_item_t::unreg () { if (NULL != root_slice_ && (prev_ != reinterpret_cast<unw_item_t *>(~0))) { root_slice_->objs_ = prev_; prev_ = reinterpret_cast<unw_item_t *>(~0); } }

次に、例外を発生させてスタックを昇格させるプロセスを検討します。

 static int pop_slice () { jmp_buf_splice *sl = root_slice_; assert (NULL != sl); root_slice_ = sl->prev_; return 0; } int throw_slice (const char *str, bool popstate) { if (NULL == str) return -1; jmp_buf_splice *sl = root_slice_; unw_item_t *obj = root_slice_->objs_; while (NULL != obj) { unw_item_t *tmp = obj; obj = obj->prev_; tmp->~unw_item_t (); } if (popstate) pop_slice (); longjmp (sl->buf_, int(str)); return 0; }

サービスクラス-stdのアナログ:: auto_ptr：

  template<typename cl> class deleter_t : public unw_item_t { public: deleter_t (cl *obj){ptr_ = obj;}; virtual ~deleter_t () {delete ptr_;}; private: cl *ptr_; deleter_t (); deleter_t (const deleter_t &); deleter_t &operator= (const deleter_t &); };

サービスクラス-配列：

 template<typename cl> class vec_deleter_t : public unw_item_t { public: vec_deleter_t (cl *obj){ptr_ = obj;}; virtual ~ vec_deleter_t () {delete [] ptr_;}; private: cl *ptr_; vec_deleter_t (); vec_deleter_t (const vec_deleter_t &); vec_deleter_t &operator= (const vec_deleter_t &); };

例。

テストクラス

 class _A { public: _A():val_(++cnt_){printf ("A::A(%d)\n",val_);} _A(int i):val_(i){printf ("A::A(%d)\n",val_);} virtual ~_A(){printf ("A::~A(%d)\n",val_);} static int cnt_; }; int _A::cnt_ = 0; class A : public unw_item_t, _A {};

例1

 A a(1); TRY_BLOCK { A b(2); THROW_IN_BLOCK("error\n"); std::cerr << "notreached\n"; } CATCH_BLOCK_FIN { std::cerr << __exc; } FIN_BLOCK;

A :: A（1）
A :: A（2）
A ::〜A（2）
エラー
A ::〜A（1）

例2

 A a(1); TRY_BLOCK { A b(2); TRY_BLOCK { A c(3); THROW_IN_BLOCK("error\n"); std::cerr << "notreached\n"; } CATCH_BLOCK_FIN { std::cerr << "." << __exc; RETHROW_IN_BLOCK; } FIN_BLOCK; std::cerr << "notreached\n"; } CATCH_BLOCK_FIN { std::cerr << ".." << __exc; } FIN_BLOCK;

A :: A（1）
A :: A（2）
A :: A（3）
A ::〜A（3）
.error
A ::〜A（2）
..エラー
A ::〜A（1）

例3

  TRY_BLOCK { vec_deleter_t<_A> da(new _A[3]); TRY_BLOCK { THROW_IN_BLOCK("error\n"); std::cerr << "notreached\n"; } CATCH_BLOCK_FIN { std::cerr << "." << __exc; RETHROW_IN_BLOCK; } FIN_BLOCK; std::cerr << "notreached\n"; } CATCH_BLOCK_FIN { std::cerr << ".." << __exc; } FIN_BLOCK;

A :: A（1）
A :: A（2）
A :: A（3）
.error
A ::〜A（3）
A ::〜A（2）
A ::〜A（1）
..エラー

制限事項
このソリューションには多くの欠点があります。

デストラクタで例外をスローすることはできません。 unw_item_tデストラクタはこのインスタンスへのリンクをまだ削除していません。その結果、デストラクタが再度呼び出されます。
new演算子を使用してunw_item_tから継承したクラスのオブジェクトを作成することは非常に危険です。メモリ自体を管理している場合でも、そのようなポインタは外部のコンテキストまたは外部のストリームに落ちる可能性があり、見ているオブジェクトが突然デストラクタを引き起こし、代謝大惨事を引き起こす可能性があります。
unw_item_tから継承されたクラスを別のクラスのメンバーとして集約することはできません。そうしないと、そのデストラクターが2回呼び出されます。
説明されている方法は、ハードウェア例外と統合できません。
例外タイプの制限。上記では、文字列ポインタのみを使用しました。プリミティブ型を例外として渡す場合、選択肢は1つだけです。オブジェクトポインターを例外として使用する場合、RTTIを使用できます。次のような提案ができます
```
 #define CATCH_BLOCK_TYPED(t) \ } else if (NULL != dynamic_cast<t>(__exc)) { 
```
そしてこれにより、さまざまなタイプの例外を使用する機会が与えられます。ただし、プリミティブ型の例外をスローすることはできません。
ユーザーは、スローされた例外オブジェクトを削除する必要があります。

そしてまだ。
説明されている制限にもかかわらず、説明されている方法には固有の利点があります。

シンプル。数十行のコード-すべてが機能します。
透明性のコンセプト。
簡単な携帯性。アーキテクチャに依存しません。

利点を維持しながら、この方法の欠点を排除することは可能ですか？はい、いいえ。 C ++ツールのみを使用すると、これは不可能です。

著者は何で運転していますか？
技術的なせん妄の順序で、上記のスキームを正しく実装するためにコンパイラを変更する方法について考えますか？
上記のソリューションには何が欠けていましたか？オブジェクトの生成方法に関する知識。
たとえば、オブジェクトが共通ヒープから割り当てられたメモリ上に構築され、スレッド間で移行できる場合、ストリーム依存スタックに決して登録されるべきではありません。別のオブジェクトに集約されたオブジェクトをどこにも登録しないでください。
そして、同じタイプのオブジェクトを使用しますが、スタックメモリ上で、これを行う必要があります。もちろん、このスタックオブジェクトへのポインタを別のスレッドに渡すことは可能ですが、どのような状況でこれが役立つか想像することは困難です。
だから：

タイプTのスタックオブジェクトの場合、コンパイラは実際にタイプのラッパークラスを作成します
```
 template<class T> class __st_wrapper : public unw_item_t { public: virtual ~__st_wrapper() { unreg(); ((T*)data_)->T::~T(); }; private: char data_[sizeof(T)]; }; 
```
目的のコンストラクターTを呼び出す
jmp_buf_splice :: root_slice_クラスの静的メンバーは、TLSまたは対応するレジスタ（存在する場合）を介して実装されます。
プログラマーは、 data_にあるタイプTのオブジェクトのみを見ています。
仮想デストラクタのないスタックオブジェクトの場合、これはラッパーに表示されます
デストラクタで例外をスローできるようになりましたデストラクタ自体を呼び出す前に、登録を解除しました。
ハードウェア例外（カーネル例外）はサポートされていないため、例外がスローされる時点で、コンパイラーはどのレジスターを「着陸」させる必要があるかを認識し、そうする必要があります。
スタックオブジェクトを定期的に破棄するために、コンパイラは__st_wrapperのデストラクターへの呼び出しを作成します
適切なcatchブロックを選択するためのメカニズムはそのままです。つまりこれらのブロックの記述子がコード外にある補助テーブル情報が必要です。
setjmpのアナログを使用して制御を移行します。中間（上記の2つに関して）コントロール転送オプションを実装することを提案します。 Setjmpには重大な欠点があります-バッファサイズは非常に大きく、実際には小さな部分が使用されます。
一方、DWARFバイトコードの実行は非常に無駄が多いようです。
したがって、setjmpバッファーの代わりに、実際の値があるスタックポインターを基準にした回復とシフトを必要とするレジスターのリストを格納します。計算値の場合、値はレジスタに直接格納されます。これを行うには、追加のメモリがスタックに割り当てられ、それにシフトが与えられます。実際、一時変数が開始されます。
コンパイラーは、例外を発生させる前に、関連するすべてのデータをレジスターからアンロードします。その場合、損失なく復元できます。

それでも、 tryブロックの使用は意識的な行為であることに注意する価値があります。これには一定のコストが伴うという事実には何の問題もありません。私見これらの（中程度の）コストはさらに便利です言語ツールに対する責任ある態度を刺激します。
演算子newとnew []を呼び出すときにキャッチする例外はそのまま残されます。つまり各tryを内部tryブロックで保護し、例外が発生した場合は以前のイテレーションで作成されたすべてを破棄します。そして、もちろん、オブジェクトに割り当てられたメモリを返します[s。]
スタックオブジェクトの配列を実装するために何もする必要はありません。ただし、特別なスタックオブジェクト（ new []演算子を呼び出すときに使用されるベクトルと同様のベクトル）を実装することにより、メモリを節約できます。

ところで。

オブジェクトは、スタックであることを確認できます。これを行うには、これは現在のスレッドのスタックセグメント内になければなりません。
フックからオブジェクトを削除できますか？なぜこれが必要なのか想像できませんが、そのような機会があります。
あなたがそれを脱ぐことができるなら、あなたはそれを植えることができます。 allocaを介してスタックにメモリを割り当て、コンストラクターを強制的に呼び出して、スタックプロモーションメカニズムに接続します。
個別のデータスタックとコントロールスタックを持つアーキテクチャの場合、例外処理はリストの代わりにコントロールスタックを使用して非常に効率的に実装できます。

PS：有益な議論をしてくれたAlexander Artyushinに感謝します。

C ++例外の処理で難しいのは何ですか？

More articles: