C++相談室 part160

**デフォルトの名無しさん** · 2022/04/15(金) 08:39:32.42

前スレ
C++相談室 part158
https://mevius.5ch.net/test/read.cgi/tech/1645239402/

**デフォルトの名無しさん** · 2022/04/23(土) 19:53:40.19

>>276
そんな気持ち悪い独自仕様にして何を考えてるんだろう
余分に負担のかかるプログラミングを強いられるデメリットしかない

**デフォルトの名無しさん** · 2022/04/23(土) 20:01:38.15

>>277
独自仕様なのは別にして、そんなに気持ち悪いかなぁ？
ゼロ除算を起こした処理の周辺で局所的に対処できるのはいいと思うんだが。

**デフォルトの名無しさん** · 2022/04/23(土) 20:07:10.88

>>267
人迷惑と言う意味で一緒だよ

**デフォルトの名無しさん** · 2022/04/23(土) 20:10:26.67

お前らいつまで、そんな話ししてんだよ
世の中はさとみのお祝いムードでも盛り上がってんの二

**デフォルトの名無しさん** · 2022/04/23(土) 20:12:03.42

signal と SEH なら SEH の方がマシだな
signal ハンドラーはマルチスレッドで個々のハンドラー持てないし

**デフォルトの名無しさん** · 2022/04/23(土) 20:21:15.45

スレッド毎に設定できないシングルトンなデータといえばカレントディレクトリとか

**デフォルトの名無しさん** · 2022/04/23(土) 20:42:16.92

SEHとかのコスト掛けてするのは本末転倒
ゼロ除算は事前if文0比較でコスト安い

**デフォルトの名無しさん** · 2022/04/23(土) 21:07:07.31

例外の実装として sjlj と SEH とのどちらが優れているか、という話ではなかったのか？

**デフォルトの名無しさん** · 2022/04/23(土) 21:09:05.54

>>284
そんな実装をしている例はない
SEHも誤読でソース無し

**蟻人間** ◆T6xkBnTXz7B0 · 2022/04/23(土) 21:20:35.92

>>285
C++例外のSEHの実装例はあるよ。
MinGW gcc でもあるし、Visual C++ /SHaでもあるし。

**デフォルトの名無しさん** · 2022/04/23(土) 21:26:55.58

>>286
おまえバカなのか？
それはC++の例外(try throw catch)の実装例ではない

**蟻人間** ◆T6xkBnTXz7B0 · 2022/04/23(土) 21:29:35.47

>>287
/SHaのtry-catchでSEH機構を使ってるのは事実だし、確かめもしないやつに言われたくない。

**蟻人間** ◆T6xkBnTXz7B0 · 2022/04/23(土) 21:40:18.76

https://cutlassfish.wordpress.com/2014/08/12/mingw-w64-%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%99%E3%82%8B%E9%9A%9B%E3%81%AB%E5%BF%85%E8%A6%81%E3%81%AB%E3%81%AA%E3%82%8B%E3%82%B9%E3%83%AC%E3%83%83%E3%83%89%E3%83%A2%E3%83%87%E3%83%AB%E3%81%A8%E4%BE%8B/

MinGW-w64 の例外機構は、SJLJ、DWARF、SEHの3つ。MinGW-w64におけるC++の例外はこのいずれかで実装されている。

**デフォルトの名無しさん** · 2022/04/23(土) 21:41:28.57

それは嘘だな
例えば単純にプログラムの中でthrow投げるとする
当然SEHは使われない

**蟻人間** ◆T6xkBnTXz7B0 · 2022/04/23(土) 21:43:17.83

単純な例外処理は最適化で消えることがある。常識。

**デフォルトの名無しさん** · 2022/04/23(土) 21:46:06.95

>>291
消えない
例外時に関数は何を返す？

**蟻人間** ◆T6xkBnTXz7B0 · 2022/04/23(土) 22:07:33.30

>>292
https://stackoverflow.com/questions/3311641/c-exception-throw-catch-optimizations

Even simpler cases could be optimized, such as:

int func() {
try {
throw 42;
}catch(int x) {
return x;
}
}
The above code can be transformed into return 42. There are no technical reasons that impede it.

**蟻人間** ◆T6xkBnTXz7B0 · 2022/04/23(土) 22:09:39.97

君の単純なthrowの例では
std::terminate()
になるかもしれない。

**デフォルトの名無しさん** · 2022/04/23(土) 22:11:37.95

>>293
バカにしてるのか？
無条件にthrowされていてしかも関数呼び出しすらない
せめて関数の引数値によってthrowされるか否か変わる例にしろよ

**蟻人間** ◆T6xkBnTXz7B0 · 2022/04/23(土) 22:12:58.42

>>295
してるよ。

**デフォルトの名無しさん** · 2022/04/23(土) 22:17:03.10

・まずtryの中で別の関数を呼び出さないと最もベーシックなパターンにすらなっていない
・呼び出される別の関数の中でも特定条件時のみthrowしないと例外処理の意味を持たない

**蟻人間** ◆T6xkBnTXz7B0 · 2022/04/23(土) 22:17:27.90

君の父親は言い負かされようになると「バカにしてるのか」と言う癖があるようだね。愚かな人間ども。

**デフォルトの名無しさん** · 2022/04/23(土) 22:21:38.82

>>286,288
オプションもまともに書けないとかお前さん使ってないだろw
/EHa使っても構造化例外がcatchでキャッチできるようになるだけでthrowで構造化例外を送出できるようになるわけじゃないぞ
https://docs.microsoft.com/ja-jp/cpp/build/reference/eh-exception-handling-model?view=msvc-170

**デフォルトの名無しさん** · 2022/04/23(土) 22:21:59.63

なぜそんなおバカなコード例をわざわざ披露するのか常識を疑う

**デフォルトの名無しさん** · 2022/04/23(土) 22:24:23.21

これだから蟻人問の書き込みは全く信頼できない

**蟻人間** ◆T6xkBnTXz7B0 · 2022/04/23(土) 22:27:21.96

>>299
>throwで構造化例外を送出できるようになるわけじゃないぞ

そんなこと言ってない。構造化例外機構でthrowすると言ってるんだ。逆だよ。

**デフォルトの名無しさん** · 2022/04/23(土) 22:32:14.74

>>302
君は理解力がないのかね？
それだと君の主張『C++の例外がSEHで実装されている』の例になっていない

**蟻人間** ◆T6xkBnTXz7B0 · 2022/04/23(土) 22:34:18.65

>>299
>オプションもまともに書けないとかお前さん使ってないだろw

今、メタバースの中から書き込んでいて、ちょっと打ち間違えたんだ。

**蟻人間** ◆T6xkBnTXz7B0 · 2022/04/23(土) 22:38:25.54

>>303
SEHを知らん人にいちいち教えるのは授業料がかかるが。

**蟻人間** ◆T6xkBnTXz7B0 · 2022/04/23(土) 22:43:43.42

例外機構をsjljで実装するのもsehで実装するのもMinGWにある。君はいつまでも駄々っ子みたいに存在を認めないんだね。

**デフォルトの名無しさん** · 2022/04/23(土) 22:45:00.85

行き詰まった敗者の典型パターン
「授業料払わないやつには教えない」
「教えて欲しかったら金払え」
「業務でもないのに答えられるか」

**デフォルトの名無しさん** · 2022/04/23(土) 22:58:24.91

SEHでC++のtry-catchを実装とか意味不明な主張してるんだな

**蟻人間** ◆T6xkBnTXz7B0 · 2022/04/23(土) 23:01:30.10

MinGW-w64 SEH版の例外機構はSEHで実装されている(公開情報)。これを否定から入るなら議論はできない。

**デフォルトの名無しさん** · 2022/04/23(土) 23:07:40.34

>>309
ソース無し
C++の例外機構にSEHは不要

**デフォルトの名無しさん** · 2022/04/23(土) 23:18:30.07

結局実装の話してる人の精神状態が心配

**デフォルトの名無しさん** · 2022/04/23(土) 23:25:16.57

そろそろc++の話ししようぜ

2項演算子.*や->*が返却するオブジェクトの型を取得したい
規格にはapplication演算子が後続する場合のみ認めているが
その際の型をコンパイル時に取得したい

さらにdeclvalに渡したい

**デフォルトの名無しさん** · 2022/04/23(土) 23:31:45.53

なぜa.bとa->bという無駄な2種類を用意したんだろう？
他の言語ではaがポインタでもa.bだよね
型から間違いが起きようがないのだからa->bは不要だと思う

**デフォルトの名無しさん** · 2022/04/23(土) 23:33:55.91

>>313
君は黙ってて、そんな低レベルな話はしていない
.*や->*なんて使ったことないだろ

**デフォルトの名無しさん** · 2022/04/23(土) 23:35:30.32

お前ら聞いても無駄だな
例外とSEHの区別が付かないレベルだろうし

**デフォルトの名無しさん** · 2022/04/23(土) 23:45:44.58

decltype(declval<Hoge*>()->*declval<Fuga Hoge::*>)とかすればいいだけじゃないの
というかoperator->*のオーバーロードが絡んでなければ右項のメンバポインタの型から直接取り出せばいいだけじゃないの
何がしたいのか分からない

**デフォルトの名無しさん** · 2022/04/24(日) 06:18:26.42

>>302
だからC++の例外（要はthrow）はSEH使ってないってこと
SEHは0除算とかメモリーアクセス違反を扱うためのものだよ
signal()に比べたらスマートな実装だと思う

**デフォルトの名無しさん** · 2022/04/24(日) 07:34:41.41

>>317
ばかじゃねーのこいつ
蟻人間の主張は「C++で例外を実現するのにSEHを使う『事もある』」と言っているんだぞ

**デフォルトの名無しさん** · 2022/04/24(日) 07:58:43.35

>>318
だからthrowを実現できてないだろ
理解出来てないのにいちいち絡んでくるなよ

**デフォルトの名無しさん** · 2022/04/24(日) 08:09:04.00

>>319
MinGW64のthrowはSEHを使ってるんだが・・・
お前本当に頭大丈夫か？

**デフォルトの名無しさん** · 2022/04/24(日) 08:14:09.42

チェックメイトだなｗ

**デフォルトの名無しさん** · 2022/04/24(日) 08:24:49.35

>>320
それ/EHaの話じゃないだろ
話の流れも読めないなら黙っとけ

**デフォルトの名無しさん** · 2022/04/24(日) 08:32:41.04

>>322
お前は>>317で「だからC++の例外（要はthrow）はSEH使ってないってこと」と言ってるだろ
それに対する反例を示しただけの話なんだが？
後出しジャンケンはなしだぞ
例えば「>>317は/EHaの話をしてるんだが」とか言うなよ

**デフォルトの名無しさん** · 2022/04/24(日) 08:44:00.70

もしかして
「__try/__except/__finallyの例外処理=SEHと思っている人」と
「それを実現するために制定されたABIのことをSEHと呼んでそのABIがC++のtry/catchの実装にも応用されていると主張する人」との間で無限に平行線になってるのか

俺は後者のつもりで聞いていたけど前者と考えると、ISO標準例外を使えなんて話が出てくるのも頷ける

**デフォルトの名無しさん** · 2022/04/24(日) 08:47:49.34

>>323
> 話の流れも読めないなら黙っとけ
> 話の流れも読めないなら黙っとけ
> 話の流れも読めないなら黙っとけ

アンカーも辿れないのかよw

**デフォルトの名無しさん** · 2022/04/24(日) 08:49:16.66

>>324
> それを実現するために制定されたABIのことをSEHと呼んで
また新しいこと言い出すアホが現れた！

**デフォルトの名無しさん** · 2022/04/24(日) 08:52:40.31

>>326
sjljと引き合いに出してたからそのレイヤーの話をしていることくらい理解してると思い込んでいたわ
すまんな

**デフォルトの名無しさん** · 2022/04/24(日) 08:56:13.74

自分の旗色が悪くなったら「話の流れを読め」とか言っちゃう人ですか？
それ物凄く曖昧な定義だね（・∀・）ﾆﾔﾆﾔ
何とでも言えちゃうじゃない
火病を起こした方が負けだよ

**デフォルトの名無しさん** · 2022/04/24(日) 09:02:44.40

勝ち負けとかどうでもいいよ
俺はこの不毛な論争の背景が理解できたと思うから
>>324の説に反論がなさそうならこれ以上同じ話を延々続けるやつは両者バーカって思いながら眺めとくね

**デフォルトの名無しさん** · 2022/04/24(日) 09:14:26.07

>>328
> アンカーも辿れないのかよw
> アンカーも辿れないのかよw
> アンカーも辿れないのかよw

**デフォルトの名無しさん** · 2022/04/24(日) 09:18:51.38

>>330
俺も本当は勝ち負けはどうでもいいんだが
こいつあまりにも論理が稚拙過ぎてまともに話も出来ないレベル
ちょっとおちょくってやったらファビョーンｗ
隣国の情緒だね

**デフォルトの名無しさん** · 2022/04/24(日) 10:39:09.68

自分の旗色が悪くなったら「おちょくってやった」とか言っちゃう人ですか？
それ物凄く曖昧な定義だね（・∀・）ﾆﾔﾆﾔ
何とでも言えちゃうじゃない
火病を起こした方が負けだよ

**デフォルトの名無しさん** · 2022/04/24(日) 11:02:54.19

>>332
オウム返ししか出来ないんだな
もしかして脳みそがすごく小さい人ですか？
いやもしかしなくても脳みそがない人ですね

**デフォルトの名無しさん** · 2022/04/24(日) 11:04:51.34

>>313
C から踏襲したのだし、 C でそう決めたときに比較できるような「他の言語」なんて無かった。
当時に知られていた比較的近い構造化された文法を持つ言語というと Pascal くらいか。
演算子を分けない選択肢もあったということは今だからわかることなんだよ。

**デフォルトの名無しさん** · 2022/04/24(日) 11:26:51.18

>>313
確かに
一演算子一義を貫きたくなる理由もわかるけどそっちの方が合理的だよね

**デフォルトの名無しさん** · 2022/04/24(日) 11:31:02.04

おいおい罵倒語はよせよ
せっかくの勝利を汚すだけだぜ

**デフォルトの名無しさん** · 2022/04/24(日) 11:33:38.91

>>335
ポインタを使っている箇所をはっきりそうと書くのはCの方針だね
でC++には参照があって、参照からメンバを指定するときはドットなんだから
実質的に313が主張するとおりにもうなってる

**デフォルトの名無しさん** · 2022/04/24(日) 11:45:40.17

>>333
そろそろ>>332におちょくられてることに気付こうか
もしかして気づくための脳みそがない人なのかな？w

**デフォルトの名無しさん** · 2022/04/24(日) 11:58:32.81

>>338
もう自分が何を書いているのかも分からないレベルで狂ってますね

**デフォルトの名無しさん** · 2022/04/24(日) 12:01:55.19

aがポインタアならa[i]は*(a + i)と同じ
b[i][j][k]と書く代わりに *(b + k + _countof(b[0][0]) * j + (_countof(b[0][0]) * _countof(b[0])) * i) と書くことができうる
から[]はポインタアについては無くても良くね

c.dは(&c)->dと同じ
c.d.e.f.g.hと書く代わりは(&(c.d.e.f.g))->hぐらいしか存在しない（d, e, f, g, hは入れ子になった構造体メンバ名
が
c->d->e->f->g->hなら (*((*((*((*((*c).d).e)).f))g)).h と書くことができうる
（d, e, f, g, hは直接的な入れ子ではないが関連を持つ構造体のメンバ名
から->は無くても良くね

以上C/C++における2大無くても良くねなぜ有るんだろう事案

**デフォルトの名無しさん** · 2022/04/24(日) 12:09:24.01

実装が楽だったから
それ以上の理由は考えるだけ無駄だと思うよ

**デフォルトの名無しさん** · 2022/04/24(日) 12:13:57.09

まつが
えますたorz
誤： c->d->e->f->g->hなら (*((*((*((*((*c).d).e)).f))g)).h と書くことができうる
正： c->d->e->f->g->hなら (*((*((*((*((*c).d)).e)).f))g)).h と書くことができうる

また、c.d.e.f.g.hは（後置演算子が優先度が高いことを利用して極力括弧を無くすとして
&(&(&(&(&c->d)->e)->f)->g)->h
になるかも、、、

**デフォルトの名無しさん** · 2022/04/24(日) 12:15:41.16

>>339
自分の旗色が悪くなったら「狂ってますね」とか言っちゃう人ですか？
それ物凄く曖昧な定義だね（・∀・）ﾆﾔﾆﾔ
何とでも言えちゃうじゃない
火病を起こした方が負けだよ

**デフォルトの名無しさん** · 2022/04/24(日) 12:17:02.35

おまえらに規格の話しをしたのが間違いだった
いつの間にかポインタの話になってて笑って草生えそう

**デフォルトの名無しさん** · 2022/04/24(日) 12:19:07.37

ｲｶﾝ駄目かorz
&を->より優先解釈させる必要があるからこうなりそう……
(&((&((&((&((&c)->d))->e))->f))->g))->h

やっぱミニマリスズムを貫くとかえって物量が増える感じに

**デフォルトの名無しさん** · 2022/04/24(日) 12:19:14.73

>>340
そうではなく
ptrが構造体へのポインタの時に
(*ptr).nameと書かなくとも
ptr.nameと書くことにしても型から判断判別可能だから
ptr->nameという記法を用意する必要なかった
って話でしょう
そして短く書けてわかりやすくてオペレータを増やす必要ないメリット

**デフォルトの名無しさん** · 2022/04/24(日) 12:25:11.79

c.d.e.f.g.h
が旧来のC++で言うところの
　c.d.e.f.g.h
　c.d.e.f.g->h
　c.d.e.f->g.h
　c.d.e.f->g->h
　c.d.e->f.g.h
　...
　c->d->e->f->g->h
（計2^5通り）のどれな意味のかが暗黙になって機械任せになってしまったら
コードを書く方も読む方も疲弊して転職しちゃいそう……

**デフォルトの名無しさん** · 2022/04/24(日) 12:31:08.83

>>312の話ですね
戻しましょうか

**デフォルトの名無しさん** · 2022/04/24(日) 12:37:13.82

>>347
C/C++以外のどの言語においても
c.dの記法しかないが困っていない
プログラミングする上で区別する必要がない

**デフォルトの名無しさん** · 2022/04/24(日) 12:57:12.43

まあPerlだと確かに$a->[$i]は${$a}[$i]と全く同じ意味なので$記法だけで困らないが
C/C++だと違うやんけ「.」と「->」に言語の存在意義レベルで重要な違いが生じているやんけ、

**デフォルトの名無しさん** · 2022/04/24(日) 13:04:18.44

perlに限らずほぼ全てのプログラミング言語でxがポインタの時もx.yと記述
ポインタか否かは自明なのだからx->y記述は不要

**デフォルトの名無しさん** · 2022/04/24(日) 13:09:38.20

歴史的経緯でそうなった以上の理由はなさそう

**デフォルトの名無しさん** · 2022/04/24(日) 13:13:17.04

SEHの話はどうなったん？
納得行ってくれたん？

**デフォルトの名無しさん** · 2022/04/24(日) 13:33:09.07

>>353
どうでもいい話だから流しておけばいいんだよ。

**デフォルトの名無しさん** · 2022/04/24(日) 13:43:07.35

>>349
型推論とか導入したくなったときにこまりそう

**デフォルトの名無しさん** · 2022/04/24(日) 13:43:26.65

まとめ
・SEHはMicrosoftによるC言語に対する拡張機能で例外を扱えるようにする
・C++には例外機構があるためSEHを使う必要はなくMicrosoftもそう推奨
・当然ほぼ同じ仕組みなので両方サポートするコンパイラは一部を共有しうる
結論
「C++例外とSEHは同じレベルで異なるものであるため、片方を使って別の片方を実装することは有り得ない」

**デフォルトの名無しさん** · 2022/04/24(日) 13:52:38.36

ということにしたいのですね。

**デフォルトの名無しさん** · 2022/04/24(日) 14:37:26.25

結局実装の話しをせずにはおれんのだよなあ

**蟻人間** ◆T6xkBnTXz7B0 · 2022/04/24(日) 14:46:41.37

SEHはアセンブリ・機械語レベルでも定義されている。
C++コンパイラ側でSEHのアセンブリを埋め込むことも可能。

**デフォルトの名無しさん** · 2022/04/24(日) 14:53:29.69

論点すり替えのゴリホーモきっしょ

**蟻人間** ◆T6xkBnTXz7B0 · 2022/04/24(日) 14:59:44.05

【確認方法】
1. MinGW-w64からx86_64-8.1.0-release-posix-seh-rt_v6-rev0.7zをダウンロードする。
2. 7-Zipを使ってx86_64-8.1.0-release-posix-seh-rt_v6-rev0.7zを展開。
3. mingw64\binフォルダで次のような内容のa.cppを作成する。

#include <stdio.h>

int *f(void) { return NULL; }

int main(void) {
try {
throw f();
} catch (...) {
printf("OK\n");
}
return 0;
}

4. 「g++ -S -O0 a.cpp -o a.asm」を実行する。
5. ファイル「a.asm」が吐き出されている。
ファイル内容は「.seh_setframe」「.seh_endprologue」「__gxx_personality_seh0」などの文字列を含んでいる。
6. gccのソースを検索すると「gxx_personality_seh0」という関数がSEHで実装されているのが確認できる。

https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d07f18009969502c25dc8/libstdc%2B%2B-v3/libsupc%2B%2B/eh_personality.cc#L804
https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d07f18009969502c25dc8/libstdc%2B%2B-v3/libsupc%2B%2B/eh_personality.cc#L355

**デフォルトの名無しさん** · 2022/04/24(日) 15:10:50.52

それは違うな
まずC++の例外のセマンティクスは定まっており実装はそれを厳守せねばならない
次にSEHのセマンティクスはC++の例外とは微妙に異なる
したがってC++の例外をSEHで実装するのは不可能

ただし実装コードの一部共有は可能
その一部共有コードの出自がSEHであればsehと名の付くものが存在しても構わない
しかしそれを持ってC++の例外がSEHで実装されているとは言わない
この点を明確に区別できない人はヤバい

**蟻人間** ◆T6xkBnTXz7B0 · 2022/04/24(日) 15:13:01.79

>>362
アセンブリレベルでセマンティクスもないだろ。

**デフォルトの名無しさん** · 2022/04/24(日) 15:19:08.93

>>363
アセンブリレベルでセマンティクスもないは草
異なる言語にセマンティクスを保持したまま変換していくコンパイラとかの意義を否定してるやん

**デフォルトの名無しさん** · 2022/04/24(日) 15:19:51.72

レイヤーが明白に異なるね
SEHでC++の例外を実装したとは言わない
C++の例外にも適用できるように拡張したアセンブリコードを共有しただけだね
これは逆の視点でも捉えることができて元々C++例外のみ対応をSEHの例外にも適用できるように拡張したアセンブリコードを共有しても同じこと

**ハノン** ◆QZaw55cn4c · 2022/04/24(日) 15:20:22.47

>>362
＞次にSEHのセマンティクスはC++の例外とは微妙に異なる

具体的にコードで示してください

**蟻人間** ◆T6xkBnTXz7B0 · 2022/04/24(日) 15:25:25.72

アセンブリレベルでC++のセマンティクスを維持しているとは考えにくい。

**蟻人間** ◆T6xkBnTXz7B0 · 2022/04/24(日) 15:27:30.57

例え違うとしてもその違う部分をカバーするコードを追加すれば実装できる。

**デフォルトの名無しさん** · 2022/04/24(日) 15:28:20.50

>>362
> 次にSEHのセマンティクスはC++の例外とは微妙に異なる
どこがどう違うのかを書けない時点でクズレスでしかない

**デフォルトの名無しさん** · 2022/04/24(日) 15:29:04.49

>>366
SEHは整数値のみ対応という点からして異なる
だからSEHそのものではC++例外を実装できない

**蟻人間** ◆T6xkBnTXz7B0 · 2022/04/24(日) 15:31:58.61

>>370
違うよ。SEHの構造化例外はデータを渡すことができる。
EXCEPTION_RECORD構造体のExceptionInformationメンバーで渡せる。

**蟻人間** ◆T6xkBnTXz7B0 · 2022/04/24(日) 15:36:02.53

>>371
そして、データはGetExceptionInformation()関数で受け取れるよ。

**デフォルトの名無しさん** · 2022/04/24(日) 15:41:20.57

>>369
マイクロソフト公式でSEHとC++例外の違いがはっきり書いてある
C++例外対応へ拡張しない限り、SEHでC++例外を実装することは不可能

https://docs.microsoft.com/ja-jp/cpp/cpp/exception-handling-differences
C構造化例外処理(SEH)とC++例外処理との主な相違点は、C++例外処理モデルが複数の型を取り扱うのに対し、C構造化例外処理(SEH)モデルは 1 つの型 (特に、unsigned int) の例外を取り扱うことです。

>>370
それはC++例外に対応するための拡張
元のSEH自体は上記マイクロソフト公式にある通り

**蟻人間** ◆T6xkBnTXz7B0 · 2022/04/24(日) 15:59:06.18

足し算と掛け算のセマンティクスが違うとしても、足し算の繰り返しで掛け算を実装できるぜ。アホか。

**デフォルトの名無しさん** · 2022/04/24(日) 16:12:31.33

>>373
コードで示せ、馬鹿

>>371-372
＞EXCEPTION_RECORD構造体のExceptionInformationメンバーで渡せる。
＞データはGetExceptionInformation()関数で受け取れる

ご教示ありがとうございます

**デフォルトの名無しさん** · 2022/04/24(日) 16:21:05.86

>>373
Microsoft公式がその見解なら決着ついたな
蟻人間が完敗