【初心者歓迎】C/C++室 Ver.104【環境依存OK】

**デフォルトの名無しさん** · 2018/12/28(金) 06:04:52.38

エスケープシーケンスやWin32APIなどの環境依存なものもOK
そのような質問は必ず環境を書きましょう
半角空白やタブでのインデントはスレに貼ると無くなります

コードを貼れる所
http://codepad.org/
https://ideone.com/

前スレ
【初心者歓迎】C/C++室 Ver.103【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1530384293/

**デフォルトの名無しさん** · 2019/01/17(木) 02:01:31.97

このスレ、初心者を見下す者ばかりだし、

何が　【初心者歓迎】だよ。
【初心者歓迎】はずせ。

そう言うと、「何にもそんなことしてないよ」
とか、レスが来る。
子供スレ。

**デフォルトの名無しさん** · 2019/01/17(木) 08:10:37.95

optionalはヒープ使わないだけでnullと大差ない
せっかく静的にnot nulが保証されてるとこを壊してしまう
ほとんどアンチパターン

**デフォルトの名無しさん** · 2019/01/17(木) 08:21:29.72

業務でC++使ってない雑魚の意見なんて無視しろ

**デフォルトの名無しさん** · 2019/01/17(木) 08:22:23.19

趣味でC++齧ってるやつと本気で仕事としてやってるやつじゃ格が違うんだよ

**デフォルトの名無しさん** · 2019/01/17(木) 08:22:55.36

C++では好きなだけ効率を犠牲にして安全を手にすることができる
効率を犠牲にして安全を手にすることを余儀なくされている言語とは区別すべきだ

**デフォルトの名無しさん** · 2019/01/17(木) 08:47:23.41

業務で使ってない素人は平気で例外禁則とか言って返り値チェックで死ぬほど汚いコード書くんだよな

**デフォルトの名無しさん** · 2019/01/17(木) 09:07:15.76

まぁ業務と違って趣味は時間を無駄につぎ込めるから
人によっては素人の方がレベル高かったりするけどな

そういうのと比較するのはホントやめて欲しい

**デフォルトの名無しさん** · 2019/01/17(木) 09:09:21.72

>>164
は？業務と趣味でやってる奴が一番最強

**デフォルトの名無しさん** · 2019/01/17(木) 10:35:25.89

>>159
optionalの理解間違ってるよ

**デフォルトの名無しさん** · 2019/01/17(木) 10:39:29.94

>>163
例外禁止されるのは業務の方だろ
一見汚くなるがそちらの方がバグが少なくメンテしやすいという判断で
トップダウンで強制される
趣味なら最新の機能ばんばん使って自由にやりゃいい

**デフォルトの名無しさん** · 2019/01/17(木) 12:13:15.88

実際には例外を禁止するとバグが増えてメンテしにくくなるんだけどな

**デフォルトの名無しさん** · 2019/01/17(木) 13:51:39.37

そのソフトが気に入らないなら、
そのソフトを使わなきゃ良いだけだし。
そんなことも、いい年になって、わからないのか。

**デフォルトの名無しさん** · 2019/01/17(木) 14:34:02.57

このスレ卒業死体

**デフォルトの名無しさん** · 2019/01/17(木) 14:43:25.66

スレばいいじゃない

**デフォルトの名無しさん** · 2019/01/17(木) 15:55:58.66

setjmp 使えばよろし

**デフォルトの名無しさん** · 2019/01/17(木) 17:20:21.35

遂に中級者になるのか……

**さまよえる蟻人間** ◆T6xkBnTXz7B0 · 2019/01/17(木) 20:25:15.31

>>173
なんでID消えてるの？

**デフォルトの名無しさん** · 2019/01/17(木) 20:47:04.58

浪人で消してるんでっしゃろ

**デフォルトの名無しさん** · 2019/01/17(木) 21:54:16.18

単なるエラーを返すのに例外機構みたいな大域脱出って牛刀感あるよな。

**デフォルトの名無しさん** · 2019/01/17(木) 22:25:28.97

エラーコードの取り間違いやチェック漏れがないように書くにはすごい集中力が必要で神経をすり減らす作業
スローすれば僅かな労力で安全に済むところをわざわざ戻り値にするのは事を大げさにするだけ

**デフォルトの名無しさん** · 2019/01/17(木) 23:05:50.61

つ errno

**デフォルトの名無しさん** · 2019/01/17(木) 23:24:18.46

なあに、例外のcatch漏れや例外安全を欠いていないか注意するのと比べたら
たいてい局所的に判断できるから大したことない。

>エラーコードの取り間違いやチェック漏れがないように書くにはすごい集中力が必要で神経をすり減らす作業

検査例外じゃない例外機構でそれを保証するのも簡単じゃないと思うがな。
まぁ、一人開発で投げるのもcatchするのも全部把握しているという前提ならわからんでもないが。

**はちみつ餃子** ◆8X2XSCHEME · 2019/01/18(金) 00:32:34.20

>>179
そのへんはチェックするツールとかあったりしない？
知らんけど。

**デフォルトの名無しさん** · 2019/01/18(金) 00:49:25.33

実はキャッチ漏れは戻り値処理漏れよりはるかに少ない
戻り値処理はその場でエラー処理したくない場合にも一度変数に受け取って分岐を入れて呼び元に返すということを繰り返さなければならない
なので処理漏れを起こしうる確率が呼び出し箇所の数に比例して増えていくことになる
そして本当のエラー処理をしたい場所が隠れてしまいコードの可読性が低下する
可読性が低下すればミスがさらに増える
例外なら処理したくない場合は何も書かなくていいので間違えようがないので安心
またエラー処理をしたいまさにその箇所だけに処理を書けばいいのでコードの見通しが非常に良くなりミスも激減する

エラーコード戻し安全なコードを書くことは実は非常に難しい
エラーコードチェックのせいで無駄な変数と分岐が大増殖するので正確にシステムの状態を追うことが困難になりミスが増える
例外を使えばフローが非常に単調で綺麗になるので安全なコードを書くのも簡単になる

**デフォルトの名無しさん** · 2019/01/18(金) 01:03:26.14

同じ理由で、忌み嫌われてるgoto文も、実はけっこう便利だと思う

**はちみつ餃子** ◆8X2XSCHEME · 2019/01/18(金) 01:11:53.91

正しく使えば何だって便利だし、
駄目な使い方をすれば何だって駄目だっていう
すごく当たり前すぎる話

**デフォルトの名無しさん** · 2019/01/18(金) 08:10:56.74

>>183
>>180
プログラミング辞めてツールでチェックしてもらえば？

**デフォルトの名無しさん** · 2019/01/18(金) 08:14:02.62

>>180
それが検査例外じゃないかな。
いろいろ批判もあるけど、例外の内容に応じてそれぞれ異なるリカバリを確実に行うことを
保証する手段としては今のところそれ以外無いかなと思う。
まぁ、erlang/swiftあるいはgoのpanicのように、エラーの種類なんて気にせず「この下の
処理が失敗した」とだけ捉えるのが例外の扱いとして妥当なところかも。

**デフォルトの名無しさん** · 2019/01/18(金) 09:51:47.22

>>181
使い捨てでないまともなプログラムはいたるところにエラーリカバリー処理が入る
つまり例外だといたるところにtry catchかつ外に投げる例外は誰がcatchするのか仕様が複雑
仕事で大規模なプロジェクトに関わったことない人はこういうのが理解できていない

**デフォルトの名無しさん** · 2019/01/18(金) 10:01:53.52

例外押しのやつはどうせほとんどcatchせずにそのままexitさせてるだろ
exitするぐらいなら異常が発生した場所でabortする方がはるかにいい
確実にスタックダンプが残せる

**デフォルトの名無しさん** · 2019/01/18(金) 10:41:00.50

例外が有用なのってネットワークとストレージのioぐらいという認識
それ以外で必要性を感じない
配列外アクセスとかで例外とばすなと思う

**デフォルトの名無しさん** · 2019/01/18(金) 11:40:22.57

>>188
そういうバグが原因の例外はcatchしなければいいんでは？

**デフォルトの名無しさん** · 2019/01/18(金) 13:31:14.01

>>189
だから現実的にそういうのに例外をなげる仕様にありがたみがないでしょ

**デフォルトの名無しさん** · 2019/01/18(金) 13:49:33.80

>>190
なんで？SEGVも起こさずに潜在的なバグとして残り続けるよりよくない？

**デフォルトの名無しさん** · 2019/01/18(金) 13:57:52.52

>>191
自分でcatchするならtry catchがうざい
バグ扱いでcatchしないならそもそも例外投げずにpanicされた方が調査が楽
また下手にどこかでcatchされたらバグに気づかない危険性がある

以上の理由により

**デフォルトの名無しさん** · 2019/01/18(金) 16:42:12.57

gotoなんか品質チェックに問答無用で引っ掛かる

**デフォルトの名無しさん** · 2019/01/18(金) 16:50:08.01

お間抜けな品質チェックだこと

**デフォルトの名無しさん** · 2019/01/18(金) 17:34:28.42

ID:cHsPUmRi ってcatchで全ての例外がキャッチされると思ってるのか？

**デフォルトの名無しさん** · 2019/01/18(金) 17:42:49.84

例外が発生しました

「このPCの電源が入っていません」

**デフォルトの名無しさん** · 2019/01/18(金) 17:59:44.06

例外機構は誰がキャッチするのか別の問題を作った
問題先送りで日本人らしい
結局本質的には何の解決ももたらさなかった
例外機構はオカルトだったんだ。占いの類

**さまよえる蟻人間** ◆T6xkBnTXz7B0 · 2019/01/18(金) 18:01:08.56

例外なくしてOS作れるか？

**はちみつ餃子** ◆8X2XSCHEME · 2019/01/18(金) 18:48:44.03

>>197
エラーを返却値で返すことにしたところでそれは同じでしょ。
どこまで上に (返却値によって) 伝播すべきかってのは
どこでキャッチすべきかと問題は同じだよ。

**デフォルトの名無しさん** · 2019/01/18(金) 18:57:17.35

ダウソファイルのファイル名置換する簡単なプログラムをC++とC#で書いてみた(C++で作って、それ見ながらC#に変換した)
もともとシェルスクリプトでもいいようなプログラムなんで実行速度とかどーでもいい
コンパイル時間長が
C# <<< 超えられない壁 <<< C++
C++のコンパイル時間と比べるとC#は一瞬で完了する。これは、快適性がだんちだな。

**デフォルトの名無しさん** · 2019/01/18(金) 19:12:22.57

if文使うな。
ということか？

**デフォルトの名無しさん** · 2019/01/18(金) 20:07:49.64

リターンコードスタイルにすると

無駄な変数が増える
無駄な分岐が増える
エラーコード追加時に全ての呼び出し元を精査しなければならない
エラーに付随する情報を伝達する標準的な規則が存在しない
全ての正常系の処理にコードチェックのオーバーヘッドが追加される
ライブラリ内部で発生する例外への対処が困難(例外を基本としていれば容易に対処可能)
参照透過性が壊滅する

デメリットだらけ

**デフォルトの名無しさん** · 2019/01/18(金) 20:59:01.43

>エラーコード追加時に全ての呼び出し元を精査しなければならない
>参照透過性が壊滅する

例外ならそれが解決すると考えているならちょっとやばい。

**デフォルトの名無しさん** · 2019/01/18(金) 23:06:15.78

>>203
返り値でエラー通知するようなセピア色の世界にいるとわからんかもしれんが普通に解決するぞ

**デフォルトの名無しさん** · 2019/01/19(土) 01:49:00.66

参照透過性ってそういう意味だっけ？w
最近例外ない言語増えてる事実はどう考える？

**デフォルトの名無しさん** · 2019/01/19(土) 07:07:12.07

>>203
リターンコード方式や例外と参照透過性になんの関係があるんだろう…

>>205
> 最近例外ない言語増えてる事実はどう考える？
Go以外にあったっけ？

**デフォルトの名無しさん** · 2019/01/19(土) 07:37:40.03

まぁ、実際関係ないね。
同じ入力に対して常に同じエラーコードを返すなら参照透過性があると言えるし、
入力によらず場合によって例外を返すことがあるなら参照透過じゃない。

**デフォルトの名無しさん** · 2019/01/19(土) 07:43:37.22

「呼び出し元を精査」とかプログラム内のデバッグに例外使ってるような書き方やね
例外処理は外部的要因（ハード、通信等）のエラーのように自分の責任外のエラーを積極的に通知するために使うべきだと思うけどな

**デフォルトの名無しさん** · 2019/01/19(土) 08:51:08.36

戻り値形式ではそもそも式として書けないから参照透過性もクソもないということをまずは理解しろ

int h(P const & p, Q const & q, Z & out_z) {
X x;
Int ret_f = f(p, x); // out ref x
if (is_error(ret_f)) return ret_f;
Y y;
int ret_g = g(q, y); // out ref y
if (is_error(ret_g)) return ret_g;
z = x * y;
return RET_OK;
}

↑例外を使わない下品すぎるコード
↓例外を使ったスーパーエレガントなコード

Z h(P const & p, Q const & q) { return f(p) * g(q); }

**デフォルトの名無しさん** · 2019/01/19(土) 09:21:20.09

Real Programmers Don't Use Exception.

**デフォルトの名無しさん** · 2019/01/19(土) 12:10:48.67

>>206
rust
swiftは最初なくて後で追加
積極的に使うスタンスでない

**デフォルトの名無しさん** · 2019/01/19(土) 12:13:26.40

>>209
そこに丹念なエラー処理を追加していくと、あら不思議どっちもあまりかわらない

**デフォルトの名無しさん** · 2019/01/19(土) 13:16:34.67

>>211
それってやっぱりいるじゃん
ってことだよね w

>>212
え？
何言ってるの？
エラー処理ってなんのこと？
具体的に書いてみて

**デフォルトの名無しさん** · 2019/01/19(土) 14:04:33.44

>>213
エラー処理って言ったらまぎらわしかった
異常系の対応ってこと

**デフォルトの名無しさん** · 2019/01/19(土) 14:08:49.01

何にでも丹念なエラー処理が必要になることはないし
丹念なエラー処理も例外の方がやりやすい

**デフォルトの名無しさん** · 2019/01/19(土) 14:30:15.46

>>214
エラー処理でも異常系の対応でもいいから具体的に書いてくれよ
>>209程度ならたいしたことないだろ

**デフォルトの名無しさん** · 2019/01/19(土) 14:50:30.01

案の定、参照透過性は関係ない話だった。

**デフォルトの名無しさん** · 2019/01/19(土) 16:58:07.69

>>216
具体的にするには前提がいるでしょ

f、gは外部から与えられてる関数で中身を書き換えることはできない
かつ至る所で使われている
p、qは誤りを含んでいる可能性があって、異常(エラー/例外)が起こりうる
異常の場合は何かおかしかったの後で調査できるようにログに残す、
または人間にフィードバックしてリトライさせる必要がある

製品レベルのソフトウェアならいたって普通の前提と要件
これを実現するとどうなるかは想像つくでしょ？

おれは例外否定派ではないよ
役に立つところは限定的と言う主張
>>188 がおれだから
まぁ確かにどちらかで言えばなくてもいいとは思ってる
ただ現状C++の標準ライブラリは例外ありきの設計に突き進んでいるから
エラーコードで突き進むのは筋が悪いのは確か

**デフォルトの名無しさん** · 2019/01/19(土) 17:14:14.89

>>218
> p、qは誤りを含んでいる可能性があって、異常(エラー/例外)が起こりうる
意味わからん

**デフォルトの名無しさん** · 2019/01/19(土) 17:16:52.76

コード書けないならそう言えば？
長文で言い訳してないでさ

**デフォルトの名無しさん** · 2019/01/19(土) 17:33:46.39

普通は馬鹿に割く時間がもったいないからコード書けません

**デフォルトの名無しさん** · 2019/01/19(土) 17:53:36.92

そう言ういいわけ要らんし

**デフォルトの名無しさん** · 2019/01/19(土) 18:31:39.45

信者ですらわずかなサンプルコードを書くのをためらうほどには戻り値スタイルは厄介な代物ということがわかったね
くだらない言い訳で長文を書く労力よりも高くつくということがはっきりした

**デフォルトの名無しさん** · 2019/01/19(土) 20:10:32.29

普通signalで実装するよね～

**デフォルトの名無しさん** · 2019/01/19(土) 20:17:23.95

勝利宣言の後で申し訳ないけど
h()でハンドルするとしたら単に

　　Z h(P const & p, Q const & q) {
　　　　try {
　　　　　　return f(p) * g(q)
　　　　} catch (exception_invalid_arg_f e) {
　　　　　　throw exception_invalid_arg("arg p is invalid");
　　　　} catch (exception_invalid_arg_g e) {
　　　　　　throw exception_invalid_arg("arg q is invalid");
　　　　}
　　}

みたいにリアス海岸になるわけでしょ
でもこれはpとqの異常の区別が下からあがってくる例外で区別できてしまう特殊例

　　Z h2(P const & p, Q const & q0, Q const & q1) {
　　　　return f(p) * g(q0) * g(q1);
　　}

だとより複雑になる
じゃあこれ次の人やってみて

**デフォルトの名無しさん** · 2019/01/19(土) 20:34:58.74

天狗だ天狗が出たぞぉ

**デフォルトの名無しさん** · 2019/01/19(土) 21:39:06.68

やっぱり例外機構はオカルトだった。皆が長い間この迷信に惑わされ疲弊した

**デフォルトの名無しさん** · 2019/01/19(土) 22:11:28.98

疲弊してるのは君みたいだけど w

**デフォルトの名無しさん** · 2019/01/19(土) 22:15:24.45

>>227
少し休め
人生は長いぞ

**デフォルトの名無しさん** · 2019/01/20(日) 09:40:39.15

>>225
例外の使い方知らないのか

**デフォルトの名無しさん** · 2019/01/20(日) 10:17:17.63

具体的に書いてくれよ

**デフォルトの名無しさん** · 2019/01/20(日) 10:50:52.46

>>231
まさかと思うけど>>225でcatch書かなきゃf()やg()で発生した例外はそのままh()の呼び出し側に伝搬すること知らんのか？
あと、例えば引数がおかしいと言う例外なら例外情報に引数の値などを含めて一番外側でログを採るとかするから
> 　　Z h2(P const & p, Q const & q0, Q const & q1) {
> 　　　　return f(p) * g(q0) * g(q1);
> 　　}
> だとより複雑になる
なんてことはない

**デフォルトの名無しさん** · 2019/01/20(日) 11:19:55.89

ほらな言った通りになった

戻り値スタイルはただ異常処理を上位に委ねるだけでも多量のコードを書かなければならない
だから本当に処理すべき異常や正常系の処理が異常伝達に埋もれてしまいコードの可読性が著しく低下してしまう
>>225が>>209のサンプルコードの意図を誤解した理由がこれだ
>>225が間違えたのは予想された事だったんだ

>>225が例外スタイルでは必要ない障害伝達を書いてしまった理由も根は同じ
戻り値スタイルを書き続ける事によって関数コールの周りに障害伝達を書くのは当たり前の事なんだと頭の中に刷り込まれて思考停止してしまった
結果として例外スタイルを書く際にもいつもの癖で不要な障害伝達を書いてしまった

そして戻り値スタイル派の人々は自分達が戻り値スタイルの常識にしたがって書いた例外スタイルの酷いコードを見てこう言うのだ
「ほらやっぱり例外はダメじゃないか」
とね

**デフォルトの名無しさん** · 2019/01/20(日) 11:22:27.27

ちなみに言った通りのレスは>>181のことな

**デフォルトの名無しさん** · 2019/01/20(日) 13:52:10.31

>>232
> > だとより複雑になる
> なんてことはない

具体的にコードで書けよw
要件は >>218 な
h()が異常処理の責任を持つ前提でな
上に例外伝搬させてるだけでは問題は何も解決しねーから

**デフォルトの名無しさん** · 2019/01/20(日) 14:06:11.05

あと
>>225
で例外投げなおしてるのは本質じゃない
単にそこでなにかしら異常系の対応をするという意味合い

人間にリトライさせることを考えると h()を呼び出したのがUIのフレームワークで
呼び出し側が "arg p is invalid" というメッセージでどっちの間違いが判定するなど
(現実には文字列で判定させる実装にしないだろうが、例な)

そこをそのまま exception_invalid_arg_f を上に伝搬させればいいだろと思うのはど素人
h() から外部ライブラリの exception_invalid_arg_f、exception_invalid_arg_g がそのまま
あがってくるというのは一般的にソフトウェアのレイヤー構造を崩してる
もちろん自分が担当している範囲ならありだが、
h() を外部に公開するような場合は仕様の責任をもつために自分で定義した例外で
投げなおすのは当たり前

**デフォルトの名無しさん** · 2019/01/20(日) 14:24:17.92

とりあえず戻り値スタイルでコード書いてくれよ
例外版に直してあげるからさ

**デフォルトの名無しさん** · 2019/01/20(日) 14:29:19.26

>>235
ほら何もわかってない
エラー発生箇所でなんでも解決しなきゃならないと洗脳されてんだね
何もなくてもエラー処理コードを書かなければならない戻り値スタイルの書きすぎで感覚がおかしくなってる

**デフォルトの名無しさん** · 2019/01/20(日) 14:32:48.63

printfの戻り値もチェックしろよ

**デフォルトの名無しさん** · 2019/01/20(日) 14:40:21.16

>>236
戻り値スタイルに慣れるとレイヤー境界がどこかも定義せずに例外変換をしてしまうようになっちゃうのかな
そして本当に変換が必要な例外は何かということも考えなくなってしまう
必要かどうかわからないけど何かしなきゃって強迫観念に苛まれてるのだろうね
戻り値スタイルだと伝達処理が必須だから例外スタイルになると不安になるのだろうな

**デフォルトの名無しさん** · 2019/01/20(日) 17:06:39.20

戻り値って何？

**デフォルトの名無しさん** · 2019/01/20(日) 17:27:50.05

戻り値を使う例

printf("%d\n",printf("1+2+3="));

**デフォルトの名無しさん** · 2019/01/20(日) 17:45:51.48

配列・ポインタ・構造体・クラス→「プログラミング楽勝ンゴｗｗｗｗｗｗ」

スレッド・コルーチン・テンプレート→「あばばばば・・・」

**デフォルトの名無しさん** · 2019/01/20(日) 21:20:28.02

はい誰もコード書かないw
お前らちっさいコードとか異常系の甘いコードしか書いたことないから例外マンセーなんだよ

**デフォルトの名無しさん** · 2019/01/20(日) 21:31:17.80

やっぱり例外機構はオカルトだった。皆が長い間この銀の弾丸を装った迷信に惑わされ疲弊した

**デフォルトの名無しさん** · 2019/01/20(日) 21:52:33.91

>>244
だから後出し条件出されると困るから戻り値スタイルでコード書いてくれ
って書いてあるだろ
例外とあまり変わらないんだから書けるよね？

**デフォルトの名無しさん** · 2019/01/20(日) 22:13:54.05

>>244
>>209

**はちみつ餃子** ◆8X2XSCHEME · 2019/01/20(日) 22:17:29.98

あのなぁ、俺は他の機能についての話で何度か書いてるけど、
適切な場面で適切に使えってだけの話で、
どんな機能だってそんなに万能だと思ってるやつなんていねぇよ。

どうせ回復できない異常ならちまちまと返却値をとりまわして
上まで運ぶのはクソ面倒くせぇし、
その場で対処する必要があるようなものは
try/catch よりも if で書いた方が短くて簡単だし取りこぼしにくいってのはわかる。

どちらにするべきか判断を付けるコストの方がデカいわっていう場面なら
各プロジェクトのポリシーで一方に決めつけたって別にかまわん。

当たり前すぎて主張するのがアホくさいんだけど、
そんなことは場合によるとしか言いようが無いだろ。

**デフォルトの名無しさん** · 2019/01/20(日) 22:18:21.76

異常系の処理がシビアになればなるほど例外が有利になる
リターンコードスタイルは複雑化した分岐と大量の変数のせいでミスを誘発しまくる
例外ならば必要な時に必要なだけ異常系の処理を書けばいいので混乱することはない
例外スタイルにはまったく過不足がない
やりたいことをジャストそのまま書けばよろしい

**デフォルトの名無しさん** · 2019/01/20(日) 22:25:39.40

>>248
中身のない長文は要らんよ

**デフォルトの名無しさん** · 2019/01/20(日) 22:33:30.46

例外はその機構が重いから極端な異常系にしか使わないようにしてるのも今は昔の考え方なのかな

**デフォルトの名無しさん** · 2019/01/20(日) 22:36:51.24

>>250
ここ数10レスほど続いていた中身のない不毛なやり取りより>>248の1レスの方が有意義だと思うぞ

**デフォルトの名無しさん** · 2019/01/20(日) 22:39:23.56

>>252
お前もな～

**デフォルトの名無しさん** · 2019/01/20(日) 22:55:26.02

>>251
そもそも正常系では例外の方が速い

**デフォルトの名無しさん** · 2019/01/20(日) 23:31:58.94

>戻り値スタイルに慣れるとレイヤー境界がどこかも定義せずに例外変換をしてしまうようになっちゃうのかな

レイヤーの境界やエラーの粒度の違いに頓着しないのは、どっちかというと安直に例外投げれば良いと
考えている方のような気がするがな。
この一連の発言見ても、投げた例外が誤ってレイヤー境界を越えてしまわないようどう保証するかなんて
言及してた人いないでしょ。

**はちみつ餃子** ◆8X2XSCHEME · 2019/01/21(月) 00:00:25.72

>>251
例外にもいくつかの方式があって、SJLJ ってやつは例外を投げないときもやたら遅いが、
他のほとんどの方式は例外を投げないときはゼロに近いコストのはず。

ただ、 SJLJ 以外の方法というのはデバッグ情報を使うためにツールチェインとの連携が必須だとか、
ハードウェアの機能を使うとかいった制約があって移植性に難があったりもするので、 SJLJ も滅びずに残ってる。

要するに例外の処理速度は場合によるが、
普通のデスクトップコンピュータで SJLJ を使わざるを得ないようなみみっちいツールチェイン、ハードウェアって
ことはあんまりなかろうと思う。 (ある？)

**デフォルトの名無しさん** · 2019/01/21(月) 00:16:50.05

>>255
リターンコードスタイルはレイヤ境界どころか体系的にエラー処理を考えるということをしないからなぁ
例外スタイルの人はじゃあどこで処理すんのということもちゃんと考えてる