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

1 名前：デフォルトの名無しさん mailto:sage [2018/12/28(金) 06:04:52.38 ID:ufThBpcD.net] エスケープシーケンスやWin32APIなどの環境依存なものもOK そのような質問は必ず環境を書きましょう 半角空白やタブでのインデントはスレに貼ると無くなります コードを貼れる所 codepad.org/ https://ideone.com/ 前スレ 【初心者歓迎】C/C++室 Ver.103【環境依存OK】 https://mevius.5ch.net/test/read.cgi/tech/1530384293/ 152 名前：デフォルトの名無しさん mailto:sage [2019/01/16(水) 21:54:11.46 ID:gQtWsPR9.net] じゃあLLVMのコーディングスタンダードこれな https://llvm.org/docs/CodingStandards.html 例外、RTTI、iostream使わない 現実に使えるソフトってのはこういう制約で作るわけだ C++の標準化やってる連中はメタプログラミングで遊んでるだけ 現実問題なんて何もわかってない 153 名前：デフォルトの名無しさん mailto:sage [2019/01/16(水) 23:10:45.86 ID:4t4UncJr.net] 例外使わないとかないわー 初心者かよ 154 名前：デフォルトの名無しさん mailto:sage [2019/01/16(水) 23:12:36.63 ID:Xh3PQjx5.net] だから、ブラウザ、ロケット射的距離のシミュレーション、機械学習 155 名前：デフォルトの名無しさん mailto:sage [2019/01/16(水) 23:36:41.52 ID:gQtWsPR9.net] >>153 初心者ってのはC++の例外のバイナリモデル説明できねーやつのことな 156 名前：デフォルトの名無しさん mailto:sage [2019/01/16(水) 23:44:05.56 ID:gQtWsPR9.net] >>154 でC++がそれらに対してどんな問題解決してくれたんだ？ 157 名前：はちみつ餃子 mailto:sage [2019/01/17(木) 01:07:41.88 ID:/VOhvfFp.net] >>152 そこらへんはしゃーない。 便利な機能も害悪な場面は有るし、 ある時点では有用だったものが後には足を引っ張ることもある。 あるプロジェクトで縛りを設けるからといって それが現実の全てというわけではない。 ただ、例外を使わない方向というのは大きなプロジェクトでは そこそこあるかも？ >>153 例外が忌避されるのは他の言語と接続したときに、 呼出した側が例外を捕捉できないというのが致命的で、 つまりはそういった場面が想定されるようなライブラリでの一般的な規則。 外へ出る前に例外を全部キャッチしてしまうってのでも、 まあなんとかならんことはないが、 近頃では std::optional を活用した方がいいという雰囲気はある気がするね。 Go や Rust は最初からそういう方向だし。 158 名前：デフォルトの名無しさん mailto:sage [2019/01/17(木) 02:01:31.97 ID:l+wuAult.net] このスレ、初心者を見下す者ばかりだし、 何が　【初心者歓迎】だよ。 【初心者歓迎】はずせ。 そう言うと、「何にもそんなことしてないよ」 とか、レスが来る。 子供スレ。 159 名前：デフォルトの名無しさん mailto:sage [2019/01/17(木) 08:10:37.95 ID:qOfK2eXQ.net] optionalはヒープ使わないだけでnullと大差ない せっかく静的にnot nulが保証されてるとこを壊してしまう ほとんどアンチパターン 160 名前：デフォルトの名無しさん mailto:sage [2019/01/17(木) 08:21:29.72 ID:4hvMH0x4.net] 業務でC++使ってない雑魚の意見なんて無視しろ 161 名前：デフォルトの名無しさん mailto:sage [2019/01/17(木) 08:22:23.19 ID:4hvMH0x4.net] 趣味でC++齧ってるやつと本気で仕事としてやってるやつじゃ格が違うんだよ 162 名前：デフォルトの名無しさん mailto:sage [2019/01/17(木) 08:22:55.36 .net] C++では好きなだけ効率を犠牲にして安全を手にすることができる 効率を犠牲にして安全を手にすることを余儀なくされている言語とは区別すべきだ 163 名前：デフォルトの名無しさん mailto:sage [2019/01/17(木) 08:47:23.41 ID:qOfK2eXQ.net] 業務で使ってない素人は平気で例外禁則とか言って返り値チェックで死ぬほど汚いコード書くんだよな 164 名前：デフォルトの名無しさん mailto:sage [2019/01/17(木) 09:07:15.76 ID:CHgbqTPA.net] まぁ業務と違って趣味は時間を無駄につぎ込めるから 人によっては素人の方がレベル高かったりするけどな そういうのと比較するのはホントやめて欲しい 165 名前：デフォルトの名無しさん mailto:sage [2019/01/17(木) 09:09:21.72 ID:4hvMH0x4.net] >>164 は？業務と趣味でやってる奴が一番最強 166 名前：デフォルトの名無しさん mailto:sage [2019/01/17(木) 10:35:25.89 ID:iQ0t94Qh.net] >>159 optionalの理解間違ってるよ 167 名前：デフォルトの名無しさん mailto:sage [2019/01/17(木) 10:39:29.94 ID:iQ0t94Qh.net] >>163 例外禁止されるのは業務の方だろ 一見汚くなるがそちらの方がバグが少なくメンテしやすいという判断で トップダウンで強制される 趣味なら最新の機能ばんばん使って自由にやりゃいい 168 名前：デフォルトの名無しさん mailto:sage [2019/01/17(木) 12:13:15.88 ID:oU9OMPiG.net] 実際には例外を禁止するとバグが増えてメンテしにくくなるんだけどな 169 名前：デフォルトの名無しさん mailto:sage [2019/01/17(木) 13:51:39.37 ID:l+wuAult.net] そのソフトが気に入らないなら、 そのソフトを使わなきゃ良いだけだし。 そんなことも、いい年になって、わからないのか。 170 名前：デフォルトの名無しさん [2019/01/17(木) 14:34:02.57 ID:DbtLCT5r.net] このスレ卒業死体 171 名前：デフォルトの名無しさん mailto:sage [2019/01/17(木) 14:43:25.66 ID:n6FY+cyG.net] スレばいいじゃない 172 名前：デフォルトの名無しさん mailto:sage [2019/01/17(木) 15:55:58.66 ID:K5aWd8xj.net] setjmp 使えばよろし 173 名前：デフォルトの名無しさん mailto:sage [2019/01/17(木) 17:20:21.35 .net] 遂に中級者になるのか…… 174 名前：さまよえる蟻人間 mailto:sage [2019/01/17(木) 20:25:15.31 ID:e9w/TFC0.net] >>173 なんでID消えてるの？ 175 名前：デフォルトの名無しさん mailto:sage [2019/01/17(木) 20:47:04.58 ID:iJuNblTy.net] 浪人で消してるんでっしゃろ 176 名前：デフォルトの名無しさん mailto:sage [2019/01/17(木) 21:54:16.18 ID:yb/OKoP7.net] 単なるエラーを返すのに例外機構みたいな大域脱出って牛刀感あるよな。 177 名前：デフォルトの名無しさん mailto:sage [2019/01/17(木) 22:25:28.97 ID:zQ8cL02f.net] エラーコードの取り間違いやチェック漏れがないように書くにはすごい集中力が必要で神経をすり減らす作業 スローすれば僅かな労力で安全に済むところをわざわざ戻り値にするのは事を大げさにするだけ 178 名前：デフォルトの名無しさん mailto:sage [2019/01/17(木) 23:05:50.61 ID:K5aWd8xj.net] つ errno 179 名前：デフォルトの名無しさん mailto:sage [2019/01/17(木) 23:24:18.46 ID:yb/OKoP7.net] なあに、例外のcatch漏れや例外安全を欠いていないか注意するのと比べたら たいてい局所的に判断できるから大したことない。 >エラーコードの取り間違いやチェック漏れがないように書くにはすごい集中力が必要で神経をすり減らす作業 検査例外じゃない例外機構でそれを保証するのも簡単じゃないと思うがな。 まぁ、一人開発で投げるのもcatchするのも全部把握しているという前提ならわからんでもないが。 180 名前：はちみつ餃子 mailto:sage [2019/01/18(金) 00:32:34.20 ID:ZqjXe4yq.net] >>179 そのへんはチェックするツールとかあったりしない？ 知らんけど。 181 名前：デフォルトの名無しさん mailto:sage [2019/01/18(金) 00:49:25.33 ID:HmTdANXo.net] 実はキャッチ漏れは戻り値処理漏れよりはるかに少ない 戻り値処理はその場でエラー処理したくない場合にも一度変数に受け取って分岐を入れて呼び元に返すということを繰り返さなければならない なので処理漏れを起こしうる確率が呼び出し箇所の数に比例して増えていくことになる そして本当のエラー処理をしたい場所が隠れてしまいコードの可読性が低下する 可読性が低下すればミスがさらに増える 例外なら処理したくない場合は何も書かなくていいので間違えようがないので安心 またエラー処理をしたいまさにその箇所だけに処理を書けばいいのでコードの見通しが非常に良くなりミスも激減する エラーコード戻し安全なコードを書くことは実は非常に難しい エラーコードチェックのせいで無駄な変数と分岐が大増殖するので正確にシステムの状態を追うことが困難になりミスが増える 例外を使えばフローが非常に単調で綺麗になるので安全なコードを書くのも簡単になる 182 名前：デフォルトの名無しさん mailto:sage [2019/01/18(金) 01:03:26.14 ID:0w3MYNkW.net] 同じ理由で、忌み嫌われてるgoto文も、実はけっこう便利だと思う 183 名前：はちみつ餃子 mailto:sage [2019/01/18(金) 01:11:53.91 ID:ZqjXe4yq.net] 正しく使えば何だって便利だし、 駄目な使い方をすれば何だって駄目だっていう すごく当たり前すぎる話 184 名前：デフォルトの名無しさん mailto:sage [2019/01/18(金) 08:10:56.74 ID:VfzPRVfV.net] >>183 >>180 プログラミング辞めてツールでチェックしてもらえば？ 185 名前：デフォルトの名無しさん mailto:sage [2019/01/18(金) 08:14:02.62 ID:BmxrQ6cX.net] >>180 それが検査例外じゃないかな。 いろいろ批判もあるけど、例外の内容に応じてそれぞれ異なるリカバリを確実に行うことを 保証する手段としては今のところそれ以外無いかなと思う。 まぁ、erlang/swiftあるいはgoのpanicのように、エラーの種類なんて気にせず「この下の 処理が失敗した」とだけ捉えるのが例外の扱いとして妥当なところかも。 186 名前：デフォルトの名無しさん mailto:sage [2019/01/18(金) 09:51:47.22 ID:LyFbxqMk.net] >>181 使い捨てでないまともなプログラムはいたるところにエラーリカバリー処理が入る つまり例外だといたるところにtry catchかつ外に投げる例外は誰がcatchするのか仕様が複雑 仕事で大規模なプロジェクトに関わったことない人はこういうのが理解できていない 187 名前：デフォルトの名無しさん mailto:sage [2019/01/18(金) 10:01:53.52 ID:LyFbxqMk.net] 例外押しのやつはどうせほとんどcatchせずにそのままexitさせてるだろ exitするぐらいなら異常が発生した場所でabortする方がはるかにいい 確実にスタックダンプが残せる 188 名前：デフォルトの名無しさん mailto:sage [2019/01/18(金) 10:41:00.50 ID:cHsPUmRi.net] 例外が有用なのってネットワークとストレージのioぐらいという認識 それ以外で必要性を感じない 配列外アクセスとかで例外とばすなと思う 189 名前：デフォルトの名無しさん mailto:sage [2019/01/18(金) 11:40:22.57 ID:6lA8mErY.net] >>188 そういうバグが原因の例外はcatchしなければいいんでは？ 190 名前：デフォルトの名無しさん mailto:sage [2019/01/18(金) 13:31:14.01 ID:cHsPUmRi.net] >>189 だから現実的にそういうのに例外をなげる仕様にありがたみがないでしょ 191 名前：デフォルトの名無しさん mailto:sage [2019/01/18(金) 13:49:33.80 ID:6lA8mErY.net] >>190 なんで？SEGVも起こさずに潜在的なバグとして残り続けるよりよくない？ 192 名前：デフォルトの名無しさん mailto:sage [2019/01/18(金) 13:57:52.52 ID:cHsPUmRi.net] >>191 自分でcatchするならtry catchがうざい バグ扱いでcatchしないならそもそも例外投げずにpanicされた方が調査が楽 また下手にどこかでcatchされたらバグに気づかない危険性がある 以上の理由により 193 名前：デフォルトの名無しさん mailto:sage [2019/01/18(金) 16:42:12.57 ID:MrHOaa15.net] gotoなんか品質チェックに問答無用で引っ掛かる 194 名前：デフォルトの名無しさん mailto:sage [2019/01/18(金) 16:50:08.01 ID:e8mi14LA.net] お間抜けな品質チェックだこと 195 名前：デフォルトの名無しさん mailto:sage [2019/01/18(金) 17:34:28.42 ID:dGgLcYHd.net] ID:cHsPUmRi ってcatchで全ての例外がキャッチされると思ってるのか？ 196 名前：デフォルトの名無しさん mailto:sage [2019/01/18(金) 17:42:49.84 ID:e8mi14LA.net] 例外が発生しました 「このPCの電源が入っていません」 197 名前：デフォルトの名無しさん mailto:sage [2019/01/18(金) 17:59:44.06 .net] 例外機構は誰がキャッチするのか別の問題を作った 問題先送りで日本人らしい 結局本質的には何の解決ももたらさなかった 例外機構はオカルトだったんだ。占いの類 198 名前：さまよえる蟻人間 mailto:sage [2019/01/18(金) 18:01:08.56 ID:eisM0hGT.net] 例外なくしてOS作れるか？ 199 名前：はちみつ餃子 mailto:sage [2019/01/18(金) 18:48:44.03 ID:ZqjXe4yq.net] >>197 エラーを返却値で返すことにしたところでそれは同じでしょ。 どこまで上に (返却値によって) 伝播すべきかってのは どこでキャッチすべきかと問題は同じだよ。 200 名前：デフォルトの名無しさん mailto:sage [2019/01/18(金) 18:57:17.35 ID:X3ceYQ3H.net] ダウソファイルのファイル名置換する簡単なプログラムをC++とC#で書いてみた(C++で作って、それ見ながらC#に変換した) もともとシェルスクリプトでもいいようなプログラムなんで実行速度とかどーでもいい コンパイル時間長が C# <<< 超えられない壁 <<< C++ C++のコンパイル時間と比べるとC#は一瞬で完了する。これは、快適性がだんちだな。 201 名前：デフォルトの名無しさん mailto:sage [2019/01/18(金) 19:12:22.57 ID:seZYByET.net] if文使うな。 ということか？ 202 名前：デフォルトの名無しさん mailto:sage [2019/01/18(金) 20:07:49.64 ID:BPWAMvDw.net] リターンコードスタイルにすると 無駄な変数が増える 無駄な分岐が増える エラーコード追加時に全ての呼び出し元を精査しなければならない エラーに付随する情報を伝達する標準的な規則が存在しない 全ての正常系の処理にコードチェックのオーバーヘッドが追加される ライブラリ内部で発生する例外への対処が困難(例外を基本としていれば容易に対処可能) 参照透過性が壊滅する デメリットだらけ 203 名前：デフォルトの名無しさん mailto:sage [2019/01/18(金) 20:59:01.43 ID:BmxrQ6cX.net] >エラーコード追加時に全ての呼び出し元を精査しなければならない >参照透過性が壊滅する 例外ならそれが解決すると考えているならちょっとやばい。 204 名前：デフォルトの名無しさん mailto:sage [2019/01/18(金) 23:06:15.78 ID:BPWAMvDw.net] >>203 返り値でエラー通知するようなセピア色の世界にいるとわからんかもしれんが普通に解決するぞ 205 名前：デフォルトの名無しさん mailto:sage [2019/01/19(土) 01:49:00.66 ID:gJ7zJmkH.net] 参照透過性ってそういう意味だっけ？w 最近例外ない言語増えてる事実はどう考える？ 206 名前：デフォルトの名無しさん mailto:sage [2019/01/19(土) 07:07:12.07 ID:+IqL7b8U.net] >>203 リターンコード方式や例外と参照透過性になんの関係があるんだろう… >>205 > 最近例外ない言語増えてる事実はどう考える？ Go以外にあったっけ？ 207 名前：デフォルトの名無しさん mailto:sage [2019/01/19(土) 07:37:40.03 ID:FscMnE/k.net] まぁ、実際関係ないね。 同じ入力に対して常に同じエラーコードを返すなら参照透過性があると言えるし、 入力によらず場合によって例外を返すことがあるなら参照透過じゃない。 208 名前：デフォルトの名無しさん mailto:sage [2019/01/19(土) 07:43:37.22 ID:WVD5Mi4y.net] 「呼び出し元を精査」とかプログラム内のデバッグに例外使ってるような書き方やね 例外処理は外部的要因（ハード、通信等）のエラーのように自分の責任外のエラーを積極的に通知するために使うべきだと思うけどな 209 名前：デフォルトの名無しさん mailto:sage [2019/01/19(土) 08:51:08.36 ID:fPDnzLoP.net] 戻り値形式ではそもそも式として書けないから参照透過性もクソもないということをまずは理解しろ 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); } 210 名前：デフォルトの名無しさん mailto:sage [2019/01/19(土) 09:21:20.09 ID:XwZdf3Vk.net] Real Programmers Don't Use Exception. 211 名前：デフォルトの名無しさん mailto:sage [2019/01/19(土) 12:10:48.67 ID:gJ7zJmkH.net] >>206 rust swiftは最初なくて後で追加 積極的に使うスタンスでない 212 名前：デフォルトの名無しさん mailto:sage [2019/01/19(土) 12:13:26.40 ID:gJ7zJmkH.net] >>209 そこに丹念なエラー処理を追加していくと、あら不思議どっちもあまりかわらない 213 名前：デフォルトの名無しさん mailto:sage [2019/01/19(土) 13:16:34.67 ID:+IqL7b8U.net] >>211 それってやっぱりいるじゃん ってことだよね w >>212 え？ 何言ってるの？ エラー処理ってなんのこと？ 具体的に書いてみて 214 名前：デフォルトの名無しさん mailto:sage [2019/01/19(土) 14:04:33.44 ID:gJ7zJmkH.net] >>213 エラー処理って言ったらまぎらわしかった 異常系の対応ってこと 215 名前：デフォルトの名無しさん mailto:sage [2019/01/19(土) 14:08:49.01 ID:fPDnzLoP.net] 何にでも丹念なエラー処理が必要になることはないし 丹念なエラー処理も例外の方がやりやすい 216 名前：デフォルトの名無しさん mailto:sage [2019/01/19(土) 14:30:15.46 ID:+IqL7b8U.net] >>214 エラー処理でも異常系の対応でもいいから具体的に書いてくれよ >>209程度ならたいしたことないだろ 217 名前：デフォルトの名無しさん mailto:sage [2019/01/19(土) 14:50:30.01 ID:FscMnE/k.net] 案の定、参照透過性は関係ない話だった。 218 名前：デフォルトの名無しさん mailto:sage [2019/01/19(土) 16:58:07.69 ID:gJ7zJmkH.net] >>216 具体的にするには前提がいるでしょ f、gは外部から与えられてる関数で中身を書き換えることはできない かつ至る所で使われている p、qは誤りを含んでいる可能性があって、異常(エラー/例外)が起こりうる 異常の場合は何かおかしかったの後で調査できるようにログに残す、 または人間にフィードバックしてリトライさせる必要がある 製品レベルのソフトウェアならいたって普通の前提と要件 これを実現するとどうなるかは想像つくでしょ？ おれは例外否定派ではないよ 役に立つところは限定的と言う主張 >>188 がおれだから まぁ確かにどちらかで言えばなくてもいいとは思ってる ただ現状C++の標準ライブラリは例外ありきの設計に突き進んでいるから エラーコードで突き進むのは筋が悪いのは確か 219 名前：デフォルトの名無しさん mailto:sage [2019/01/19(土) 17:14:14.89 ID:+IqL7b8U.net] >>218 > p、qは誤りを含んでいる可能性があって、異常(エラー/例外)が起こりうる 意味わからん 220 名前：デフォルトの名無しさん mailto:sage [2019/01/19(土) 17:16:52.76 ID:fPDnzLoP.net] コード書けないならそう言えば？ 長文で言い訳してないでさ 221 名前：デフォルトの名無しさん mailto:sage [2019/01/19(土) 17:33:46.39 ID:XYN5JTgF.net] 普通は馬鹿に割く時間がもったいないからコード書けません 222 名前：デフォルトの名無しさん mailto:sage [2019/01/19(土) 17:53:36.92 ID:+IqL7b8U.net] そう言ういいわけ要らんし 223 名前：デフォルトの名無しさん mailto:sage [2019/01/19(土) 18:31:39.45 ID:fPDnzLoP.net] 信者ですらわずかなサンプルコードを書くのをためらうほどには戻り値スタイルは厄介な代物ということがわかったね くだらない言い訳で長文を書く労力よりも高くつくということがはっきりした 224 名前：デフォルトの名無しさん mailto:sage [2019/01/19(土) 20:10:32.29 ID:XwZdf3Vk.net] 普通signalで実装するよね〜 225 名前：デフォルトの名無しさん mailto:sage [2019/01/19(土) 20:17:23.95 ID:gJ7zJmkH.net] 勝利宣言の後で申し訳ないけど 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); 　　} だとより複雑になる じゃあこれ次の人やってみて 226 名前：デフォルトの名無しさん mailto:sage [2019/01/19(土) 20:34:58.74 ID:DlKBTFO2.net] 天狗だ天狗が出たぞぉ 227 名前：デフォルトの名無しさん mailto:sage [2019/01/19(土) 21:39:06.68 .net] やっぱり例外機構はオカルトだった。皆が長い間この迷信に惑わされ疲弊した 228 名前：デフォルトの名無しさん mailto:sage [2019/01/19(土) 22:11:28.98 ID:+IqL7b8U.net] 疲弊してるのは君みたいだけど w 229 名前：デフォルトの名無しさん mailto:sage [2019/01/19(土) 22:15:24.45 ID:wCv/sLww.net] >>227 少し休め 人生は長いぞ 230 名前：デフォルトの名無しさん mailto:sage [2019/01/20(日) 09:40:39.15 ID:GKseTsKF.net] >>225 例外の使い方知らないのか 231 名前：デフォルトの名無しさん mailto:sage [2019/01/20(日) 10:17:17.63 ID:0AQxsU+K.net] 具体的に書いてくれよ 232 名前：デフォルトの名無しさん mailto:sage [2019/01/20(日) 10:50:52.46 ID:mVpLWWyp.net] >>231 まさかと思うけど>>225でcatch書かなきゃf()やg()で発生した例外はそのままh()の呼び出し側に伝搬すること知らんのか？ あと、例えば引数がおかしいと言う例外なら例外情報に引数の値などを含めて一番外側でログを採るとかするから > 　　Z h2(P const & p, Q const & q0, Q const & q1) { > 　　　　return f(p) * g(q0) * g(q1); > 　　} > だとより複雑になる なんてことはない 233 名前：デフォルトの名無しさん mailto:sage [2019/01/20(日) 11:19:55.89 ID:GKseTsKF.net] ほらな言った通りになった 戻り値スタイルはただ異常処理を上位に委ねるだけでも多量のコードを書かなければならない だから本当に処理すべき異常や正常系の処理が異常伝達に埋もれてしまいコードの可読性が著しく低下してしまう >>225が>>209のサンプルコードの意図を誤解した理由がこれだ >>225が間違えたのは予想された事だったんだ >>225が例外スタイルでは必要ない障害伝達を書いてしまった理由も根は同じ 戻り値スタイルを書き続ける事によって関数コールの周りに障害伝達を書くのは当たり前の事なんだと頭の中に刷り込まれて思考停止してしまった 結果として例外スタイルを書く際にもいつもの癖で不要な障害伝達を書いてしまった そして戻り値スタイル派の人々は自分達が戻り値スタイルの常識にしたがって書いた例外スタイルの酷いコードを見てこう言うのだ 「ほらやっぱり例外はダメじゃないか」 とね 234 名前：デフォルトの名無しさん mailto:sage [2019/01/20(日) 11:22:27.27 ID:GKseTsKF.net] ちなみに言った通りのレスは>>181のことな 235 名前：デフォルトの名無しさん mailto:sage [2019/01/20(日) 13:52:10.31 ID:Y8m3wOFq.net] >>232 > > だとより複雑になる > なんてことはない 具体的にコードで書けよw 要件は >>218 な h()が異常処理の責任を持つ前提でな 上に例外伝搬させてるだけでは問題は何も解決しねーから 236 名前：デフォルトの名無しさん mailto:sage [2019/01/20(日) 14:06:11.05 ID:Y8m3wOFq.net] あと >>225 で例外投げなおしてるのは本質じゃない 単にそこでなにかしら異常系の対応をするという意味合い 人間にリトライさせることを考えると h()を呼び出したのがUIのフレームワークで 呼び出し側が "arg p is invalid" というメッセージでどっちの間違いが判定するなど (現実には文字列で判定させる実装にしないだろうが、例な) そこをそのまま exception_invalid_arg_f を上に伝搬させればいいだろと思うのはど素人 h() から外部ライブラリの exception_invalid_arg_f、exception_invalid_arg_g がそのまま あがってくるというのは一般的にソフトウェアのレイヤー構造を崩してる もちろん自分が担当している範囲ならありだが、 h() を外部に公開するような場合は仕様の責任をもつために自分で定義した例外で 投げなおすのは当たり前 237 名前：デフォルトの名無しさん mailto:sage [2019/01/20(日) 14:24:17.92 ID:mVpLWWyp.net] とりあえず戻り値スタイルでコード書いてくれよ 例外版に直してあげるからさ 238 名前：デフォルトの名無しさん mailto:sage [2019/01/20(日) 14:29:19.26 ID:GKseTsKF.net] >>235 ほら何もわかってない エラー発生箇所でなんでも解決しなきゃならないと洗脳されてんだね 何もなくてもエラー処理コードを書かなければならない戻り値スタイルの書きすぎで感覚がおかしくなってる 239 名前：デフォルトの名無しさん [2019/01/20(日) 14:32:48.63 ID:Q8jHF7yk.net] printfの戻り値もチェックしろよ 240 名前：デフォルトの名無しさん mailto:sage [2019/01/20(日) 14:40:21.16 ID:GKseTsKF.net] >>236 戻り値スタイルに慣れるとレイヤー境界がどこかも定義せずに例外変換をしてしまうようになっちゃうのかな そして本当に変換が必要な例外は何かということも考えなくなってしまう 必要かどうかわからないけど何かしなきゃって強迫観念に苛まれてるのだろうね 戻り値スタイルだと伝達処理が必須だから例外スタイルになると不安になるのだろうな 241 名前：デフォルトの名無しさん mailto:sage [2019/01/20(日) 17:06:39.20 ID:z2xvgkTe.net] 戻り値って何？ 242 名前：デフォルトの名無しさん mailto:sage [2019/01/20(日) 17:27:50.05 ID:wW/QZhoY.net] 戻り値を使う例 printf("%d\n",printf("1+2+3=")); 243 名前：デフォルトの名無しさん mailto:sage [2019/01/20(日) 17:45:51.48 ID:Q2ecPa0m.net] 配列・ポインタ・構造体・クラス→「プログラミング楽勝ンゴｗｗｗｗｗｗ」 スレッド・コルーチン・テンプレート→「あばばばば・・・」 244 名前：デフォルトの名無しさん mailto:sage [2019/01/20(日) 21:20:28.02 ID:Y8m3wOFq.net] はい誰もコード書かないw お前らちっさいコードとか異常系の甘いコードしか書いたことないから例外マンセーなんだよ 245 名前：デフォルトの名無しさん mailto:sage [2019/01/20(日) 21:31:17.80 .net] やっぱり例外機構はオカルトだった。皆が長い間この銀の弾丸を装った迷信に惑わされ疲弊した 246 名前：デフォルトの名無しさん mailto:sage [2019/01/20(日) 21:52:33.91 ID:mVpLWWyp.net] >>244 だから後出し条件出されると困るから戻り値スタイルでコード書いてくれ って書いてあるだろ 例外とあまり変わらないんだから書けるよね？ 247 名前：デフォルトの名無しさん mailto:sage [2019/01/20(日) 22:13:54.05 ID:GKseTsKF.net] >>244 >>209 248 名前：はちみつ餃子 mailto:sage [2019/01/20(日) 22:17:29.98 ID:/TyOXJfP.net] あのなぁ、俺は他の機能についての話で何度か書いてるけど、 適切な場面で適切に使えってだけの話で、 どんな機能だってそんなに万能だと思ってるやつなんていねぇよ。 どうせ回復できない異常ならちまちまと返却値をとりまわして 上まで運ぶのはクソ面倒くせぇし、 その場で対処する必要があるようなものは try/catch よりも if で書いた方が短くて簡単だし取りこぼしにくいってのはわかる。 どちらにするべきか判断を付けるコストの方がデカいわっていう場面なら 各プロジェクトのポリシーで一方に決めつけたって別にかまわん。 当たり前すぎて主張するのがアホくさいんだけど、 そんなことは場合によるとしか言いようが無いだろ。 249 名前：デフォルトの名無しさん mailto:sage [2019/01/20(日) 22:18:21.76 ID:GKseTsKF.net] 異常系の処理がシビアになればなるほど例外が有利になる リターンコードスタイルは複雑化した分岐と大量の変数のせいでミスを誘発しまくる 例外ならば必要な時に必要なだけ異常系の処理を書けばいいので混乱することはない 例外スタイルにはまったく過不足がない やりたいことをジャストそのまま書けばよろしい 250 名前：デフォルトの名無しさん mailto:sage [2019/01/20(日) 22:25:39.40 ID:GTDVzsz1.net] >>248 中身のない長文は要らんよ 251 名前：デフォルトの名無しさん mailto:sage [2019/01/20(日) 22:33:30.46 ID:ps+hJNCY.net] 例外はその機構が重いから極端な異常系にしか使わないようにしてるのも今は昔の考え方なのかな 252 名前：デフォルトの名無しさん mailto:sage [2019/01/20(日) 22:36:51.24 ID:XHg9p3tl.net] >>250 ここ数10レスほど続いていた中身のない不毛なやり取りより>>248の1レスの方が有意義だと思うぞ

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef