【初心者歓迎】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/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
リターンコードスタイルはレイヤ境界どころか体系的にエラー処理を考えるということをしないからなぁ
例外スタイルの人はじゃあどこで処理すんのということもちゃんと考えてる

**デフォルトの名無しさん** · 2019/01/21(月) 02:42:47.97

例外でイベント発生させて、イベントハンドラで受けるのはど？

**デフォルトの名無しさん** · 2019/01/21(月) 06:13:04.33

>>255
> この一連の発言見ても、投げた例外が誤ってレイヤー境界を越えてしまわないようどう保証するかなんて
> 言及してた人いないでしょ。
保証は言語側でやってくれるから言及する必要がないだけのこと
そもそも例外は>>249の言う通りその場所で必要なものをキャッチして処理をすればいいだけ

**デフォルトの名無しさん** · 2019/01/21(月) 07:28:30.34

swith caseで分岐する場合もあれば、
関数へのポインタテーブル作って、ジャンプさせる場合もあるわけで、
例外も戻り値分岐も両方普通に使わないか？

C++てイベントとかイベントハンドラは環境とかboost任せで、言語仕様としては未だに確定してないのか？
C++11でようやくマルチスレッドや排他制御が仕様に盛り込まれたり、
テンプレートの仕様いじくるよりこっちの方がよっぽど大事なんじゃないのか？

**デフォルトの名無しさん** · 2019/01/21(月) 08:25:41.60

>保証は言語側でやってくれるから言及する必要がないだけのこと

保証なんてしないよね？catch忘れたらそのまま上まですっ飛んでいくだけ。
Javaのような検査例外ならそこに差異があることを意識されられるかもしれないけど。

>そもそも例外は>>249の言う通りその場所で必要なものをキャッチして処理をすればいいだけ

そこでプログラマが考える「必要なもの」から漏れた例外は上位へ渡されてしまう。
それを防ぐためには呼び出し先から送られる可能性のあるすべての例外を把握する必要があるが、
検査例外がないなら動的型付言語のように投げる側と受け取る側とで平仄を合わせてやるしかない。

**デフォルトの名無しさん** · 2019/01/21(月) 08:37:50.82

大前提が間違ってる
例外なんか最終的にはフレームワークが最上位で纏めてキャッチすりゃいいんだよ
途中でキャッチして処理するのはあくまでベターなオプションであり、それを必須とするような作りにしてはいけない

**デフォルトの名無しさん** · 2019/01/21(月) 08:55:24.27

>>261
> catch忘れたらそのまま上まですっ飛んでいくだけ。
闇雲にキャッチしたいならcatch(...)ってやればいいだけ w
> そこでプログラマが考える「必要なもの」から漏れた例外は上位へ渡されてしまう。
本来キャッチが必要な例外を漏らしているならそれはバグ
それは戻り値スタイルでも同じ話
違うのは例外はキャッチする必要の無い例外についてはそこで考慮する必要はない、自動的に上位に渡されるから上位の然るべき場所で考慮すればいいから
それが>>249の言う
> 例外ならば必要な時に必要なだけ異常系の処理を書けばいいので混乱することはない
ってこと

**デフォルトの名無しさん** · 2019/01/21(月) 08:56:49.38

>>262
半分同意。
結局のところエラーの種類に応じてきっちり対処するなら検査例外的な仕組みが必要になるが
そうでなければエラーの内容など見ずにlet it crash的に対処するしかない。
どっちつかずが一番ダメなやつ。

**デフォルトの名無しさん** · 2019/01/21(月) 08:58:29.41

(検査例外とかいうJava自身も認める失敗作は論外として、)例外機構は正しく使えばエラー処理に対する関心の分離に有効なんだよ。
ところがC++では例外を煩わしいノイズと見做す人が多い。これは即ち関心の分離ができてないわけだ。
その一番の原因は、例外型がロクに標準化されてないことだろうね。
最上位での集約処理を実現するには、下位の全てのコードが制御下になければならない。
これは膨大な既存資産と貧弱な標準ライブラリを持つC++においては非現実的な前提である。

**デフォルトの名無しさん** · 2019/01/21(月) 08:58:39.64

すべての例外を把握する必要はない
回復可能かつ回復が要件に含まれるなら個別に処理すべき
それ以外はアスペクトで処理すればいい

**デフォルトの名無しさん** · 2019/01/21(月) 09:04:47.90

>>247
だからさ、比較できるように例外スタイルで一度きちっと異常系対応して
かつスーパーエレガントなのを書いてくれよって言ってんの
お前のは体よく異常系の処理全無視してるだけじゃん

catchしたい人が必要なところでcatchすればとか言うんだろうけど
例外発生場所から遠くなればなるだけ何が原因で例外が発生して、
その回避はどうすればいいかが不明瞭になっていくってのは
散々語られてる例外の欠点

リターンコードは泥臭いが下層からくるエラーをどう処理してるかはコード見れば一目瞭然
エラーを上位に伝搬させるか、リカバリーするか、その場でクラッシュさせるか
ローカルに記述が完結できてる
APIとして外部に公開するときもインタフェースの仕様にきっちり責任持たせることができる
ちなみにプルリクでレビューする文化があればエラー無視してるような雑はコードは突き返されるだろう
見ればすぐわかるんだから
大規模な開発を経験したことない人はこういう観点でソフトウェア開発を
考えられないんだよ

最後にもう一度言っておくけどおれは例外を完全否定してるわけじゃねーから
使える場所は限られるって意見ね

**デフォルトの名無しさん** · 2019/01/21(月) 09:07:50.76

>>262
> 大前提が間違ってる
> 例外なんか最終的にはフレームワークが最上位で纏めてキャッチすりゃいいんだよ

これがど素人の意見
ソフトウェアの品質について考えたことがない

**デフォルトの名無しさん** · 2019/01/21(月) 09:11:48.87

「不正な入力です」
「ネットワークでエラーが発生しました」
「書き込みに失敗しました」

こういう情けないダイアログが表示させて終わりのアプリを作るやつね

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

>>269
それでも正常に回復できてるならそれでいいケースは多い
例外の最大の利点は例外安全さえ死守できていればアドホックな例外処理が必須でなくなることで、
より丁寧な処理が必要になれば後から追加すればよい
まあ組み込みとかやってる人には馴染まない考え方だろうね

**デフォルトの名無しさん** · 2019/01/21(月) 09:35:09.59

まあC++開発者が未処理例外=クラッシュと短絡的に考えてしまう気持ちはよく分かるよ
呼び出し階層の途中に一つでも if (hoge() != SUCCESS) errorhandle(); があれば例外安全は破綻するわけで、あまりにも非現実的

**デフォルトの名無しさん** · 2019/01/21(月) 09:54:05.98

>>267
仕様は>>218が決めるんだから>>218がコードを提示すべき
>>236みたいに後出しの条件出されても困るからな

**デフォルトの名無しさん** · 2019/01/21(月) 10:02:59.35

>>267
> 例外発生場所から遠くなればなるだけ何が原因で例外が発生して、
> その回避はどうすればいいかが不明瞭になっていくってのは
> 散々語られてる例外の欠点
それ戻り値スタイルでも同じだろ

> リターンコードは泥臭いが下層からくるエラーをどう処理してるかはコード見れば一目瞭然
だからそれはすぐ上位で処理することが前提になってるだろ
上位に何度も伝搬したら例外と同じになる上に伝搬するコードをそこら中に書く羽目になる

> ちなみにプルリクでレビューする文化があればエラー無視してるような雑はコードは突き返されるだろう
例外処理を書かないことはエラーを無視するんじゃなくてそのまま上位に伝搬してるだけ
書かないと無視してると取るのは例外をきちんと理解してないってこと

> 見ればすぐわかるんだから
お前の能力がな w

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

>>267
例外を使いこなせていないね

例外の型とパラメータをみれば何が起こったかはっきりわかる
おそらく君は例外の種類を使い分ける習慣がないだろ？
あったとしてもせいぜい標準ライブラリの例外をなんとなくふり分ける程度だろうね
でないとこんな発言はしないから
まずは例外を定義するところから初めてごらん

それと大規模開発をしたことがないのはそちらだろう
関数コールするたびにずらずらと変数や分岐を書かれたらあっという間に管理不能になる
大規模だからこそ標準的なコード、必要十分なコードというのが大切になる

**デフォルトの名無しさん** · 2019/01/21(月) 12:52:23.62

リターンコードスタイルをレビューに出すと袋叩きにされるぞ

・ノイズが多すぎて正常系のレビューが不可能
・同じくどのエラーが上位伝達、エラー変換、共通対応、個別対応なのか見てすぐにわからない
・同じく要件漏れを見落としやすい
・正常系、異常系、判断、伝達などあらゆる要素が密集して強く結合しているため仕様変更があった場合の影響が大きすぎてレビューしきれない

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

>>275
考え方自体には同意するけど、>>271で示したように例外安全が破綻しているケースについてどう考える?
エラーコードを前提にクリーンアップ処理が記述されているコードが混入しているような場合ね
あくまでC++に限った話だけど、大規模開発で完全な例外安全を維持するのは極めて困難だか実際には絵に書いた餅と思ってる

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

>>276
訂正
極めて困難で、実際には絵に描いた餅

**デフォルトの名無しさん** · 2019/01/21(月) 13:05:57.47

レビュアーの経験値不足って感が否めない

**デフォルトの名無しさん** · 2019/01/21(月) 13:14:15.22

>>276-277
必要なら直せばいいだけ
非常に稀な事象についてまで例外安全を遵守する必要はないでしょ
そもそもそういう変なコードが混入してる体質の組織で何を言ってるんだよ？って話だと思うけど

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

>>279
文化と素養の問題だよ
例外の是非でこれだけ荒れる現状を見てれば、例外のスルーなんて怖くてできねえよ
そりゃあんたが全てのコードをレビューしてマサカリ投げまくってくれるなら別だけどねえ

**デフォルトの名無しさん** · 2019/01/21(月) 13:46:08.82

>>280
ごめん、言ってることがよくわからん
そもそも
if (hoge() != SUCCESS) errorhandle();
なんてコードがあったら戻り値スタイルでもどうしようもない
例外は魔法の杖じゃないんだから何でもかんでも例外使えば解決するわけじゃなくて戻り値スタイルより楽にできるというだけの事だよ
プログラムがデカくなるほどその差は開くけど

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

>>281
result = hogehoge();
if (failure(result)) エラー処理();
リソース解放();
これhogehogeが例外起こしたらリークするだろ

**デフォルトの名無しさん** · 2019/01/21(月) 15:09:35.03

>>282
スマートポインタ使うなりcatchしてリソース解放して例外再送出するなりいくらでもやりようはあるだろ…
ちょっとレベル低くね？

**デフォルトの名無しさん** · 2019/01/21(月) 15:25:30.15

>>283
だからそれが例外安全だよ
勉強になったね

**デフォルトの名無しさん** · 2019/01/21(月) 15:27:04.68

流石に恥ずかしくね？ w

**デフォルトの名無しさん** · 2019/01/21(月) 15:51:37.78

>>283
基本的にデストラクタやリソース開放系は例外投げられると大変なことになる
catchしてなんて簡単にいってるけどもcatch(...)をそこに入れることになるのはわかるかね

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

で、そんな当たり前のことを言って何が言いたいの？
聞きかじりの知識を披露してるとしか思えないんだが… w

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

例外機構は宗教
多くの人が正しいと盲信しているに過ぎない

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

戻り値でイベント投げるという選択肢がない言語使用自体くそじゃね？

**デフォルトの名無しさん** · 2019/01/21(月) 22:06:05.18

Cにそんな機能あったっけ？
それとも別の言語の信者が折伏に来ているの？

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

>>265
そう、検査例外を正しく使うのはしばしば困難で批判も多いな。ただ、呼び出す処理がどのような
例外を返すか、静的な型検査による保証を与えてくれる仕組みとしては他に無いのも事実。

検査例外を否定するのであれば例外型に頼らない(>>264の後者)か、プログラマの努力で
整合をとってやる(>>261の最後)カウボーイ的プログラミングになる。
>>265はあくまでも例外に型を期待しているようだからカウボーイの方なんだろう。

◆QZaw55cn4c · 2019/01/21(月) 23:52:35.55

>>291
＞プログラマの努力で整合をとってやる(>>261の最後)カウボーイ的プログラミングになる。

…
…
これって「カウボーイ的」と形容されるべきものだったんですか？

catch の引数は値ではなくて、「型」だから、
テキトーな super class ERROR の下に個別エラー用派生クラスを列挙しておき、
臨機応変に catch (ERROR &e) を噛ましています…

>>256
一応例外を投げておくけれども、まじめにサポートする気はさらさらなく、
そもそもやる気は皆無・全くゼロであることを、ただ、それだけを全心全霊で表現するためだけに

throw 13;

**はちみつ餃子** ◆8X2XSCHEME · 2019/01/22(火) 02:54:09.24

例外の処理速度については、こういう提案もある。

https://ezoeryou.github.io/blog/article/2018-07-10-static-exception.html

要するに、投げるオブジェクトが条件を満たすときは、
暗黙の返却値のような形で例外を伝播する仕組み。
バイナリレベルの取り扱いも ABI を決めさえすれば済むだろうし、
互換性も確保しやすそうに思う。

**デフォルトの名無しさん** · 2019/01/22(火) 07:12:53.52

どう見ても例外否定派の方が宗教がかってる…

**デフォルトの名無しさん** · 2019/01/22(火) 08:50:21.38

環境の方の質問NGなら完全スルーでお願いします

Windows8.1 64bit のうえで Windows98SE でも動く C のバイナリを作ろうと思ってるのですが
LSI C 試食版以外に何か良い方法がないかなあと…

Windows98SE の方に Visual C++ 6.0 & SP6 をインストールしても良いのかも知れませんが
DLL の整合性とか不安
VC++ 2005 は iso 持ってるだけ…Windows98SE で動くバイナリが生成できるとか何とか

**デフォルトの名無しさん** · 2019/01/22(火) 09:09:13.74

業務で使った経験は一切ないです
使い捨てレベルのものを書くのが目的です