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

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 2ch.scのread.cgiへ]
Update time : 04/20 12:41 / Filesize : 255 KB / Number-of Response : 872
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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/
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レスの方が有意義だと思うぞ
253 名前：デフォルトの名無しさん mailto:sage [2019/01/20(日) 22:39:23.56 ID:GTDVzsz1.net]: >>252
お前もな～
254 名前：デフォルトの名無しさん mailto:sage [2019/01/20(日) 22:55:26.02 ID:GKseTsKF.net]: >>251
そもそも正常系では例外の方が速い
255 名前：デフォルトの名無しさん mailto:sage [2019/01/20(日) 23:31:58.94 ID:PO2ZqArQ.net]: >戻り値スタイルに慣れるとレイヤー境界がどこかも定義せずに例外変換をしてしまうようになっちゃうのかな

レイヤーの境界やエラーの粒度の違いに頓着しないのは、どっちかというと安直に例外投げれば良いと
考えている方のような気がするがな。
この一連の発言見ても、投げた例外が誤ってレイヤー境界を越えてしまわないようどう保証するかなんて
言及してた人いないでしょ。
256 名前：はちみつ餃子 mailto:sage [2019/01/21(月) 00:00:25.72 ID:seIeK7lJ.net]: >>251
例外にもいくつかの方式があって、SJLJ ってやつは例外を投げないときもやたら遅いが、
他のほとんどの方式は例外を投げないときはゼロに近いコストのはず。

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

要するに例外の処理速度は場合によるが、
普通のデスクトップコンピュータで SJLJ を使わざるを得ないようなみみっちいツールチェイン、ハードウェアって
ことはあんまりなかろうと思う。 (ある？)
257 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 00:16:50.05 ID:xYP7RvSv.net]: >>255
リターンコードスタイルはレイヤ境界どころか体系的にエラー処理を考えるということをしないからなぁ
例外スタイルの人はじゃあどこで処理すんのということもちゃんと考えてる
258 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 02:42:47.97 ID:sP4gcHu6.net]: 例外でイベント発生させて、イベントハンドラで受けるのはど？
259 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 06:13:04.33 ID:NbFzEAOW.net]: >>255
> この一連の発言見ても、投げた例外が誤ってレイヤー境界を越えてしまわないようどう保証するかなんて
> 言及してた人いないでしょ。
保証は言語側でやってくれるから言及する必要がないだけのこと
そもそも例外は>>249の言う通りその場所で必要なものをキャッチして処理をすればいいだけ
260 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 07:28:30.34 ID:sP4gcHu6.net]: swith caseで分岐する場合もあれば、
関数へのポインタテーブル作って、ジャンプさせる場合もあるわけで、
例外も戻り値分岐も両方普通に使わないか？

C++てイベントとかイベントハンドラは環境とかboost任せで、言語仕様としては未だに確定してないのか？
C++11でようやくマルチスレッドや排他制御が仕様に盛り込まれたり、
テンプレートの仕様いじくるよりこっちの方がよっぽど大事なんじゃないのか？
261 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 08:25:41.60 ID:vJCo0PxF.net]: >保証は言語側でやってくれるから言及する必要がないだけのこと

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

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

そこでプログラマが考える「必要なもの」から漏れた例外は上位へ渡されてしまう。
それを防ぐためには呼び出し先から送られる可能性のあるすべての例外を把握する必要があるが、
検査例外がないなら動的型付言語のように投げる側と受け取る側とで平仄を合わせてやるしかない。
262 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 08:37:50.82 ID:Kndge7xV.net]: 大前提が間違ってる
例外なんか最終的にはフレームワークが最上位で纏めてキャッチすりゃいいんだよ
途中でキャッチして処理するのはあくまでベターなオプションであり、それを必須とするような作りにしてはいけない
263 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 08:55:24.27 ID:NbFzEAOW.net]: >>261
> catch忘れたらそのまま上まですっ飛んでいくだけ。
闇雲にキャッチしたいならcatch(...)ってやればいいだけ w
> そこでプログラマが考える「必要なもの」から漏れた例外は上位へ渡されてしまう。
本来キャッチが必要な例外を漏らしているならそれはバグ
それは戻り値スタイルでも同じ話
違うのは例外はキャッチする必要の無い例外についてはそこで考慮する必要はない、自動的に上位に渡されるから上位の然るべき場所で考慮すればいいから
それが>>249の言う
> 例外ならば必要な時に必要なだけ異常系の処理を書けばいいので混乱することはない
ってこと
264 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 08:56:49.38 ID:vJCo0PxF.net]: >>262
半分同意。
結局のところエラーの種類に応じてきっちり対処するなら検査例外的な仕組みが必要になるが
そうでなければエラーの内容など見ずにlet it crash的に対処するしかない。
どっちつかずが一番ダメなやつ。
265 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 08:58:29.41 ID:Kndge7xV.net]: (検査例外とかいうJava自身も認める失敗作は論外として、)例外機構は正しく使えばエラー処理に対する関心の分離に有効なんだよ。
ところがC++では例外を煩わしいノイズと見做す人が多い。これは即ち関心の分離ができてないわけだ。
その一番の原因は、例外型がロクに標準化されてないことだろうね。
最上位での集約処理を実現するには、下位の全てのコードが制御下になければならない。
これは膨大な既存資産と貧弱な標準ライブラリを持つC++においては非現実的な前提である。
266 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 08:58:39.64 ID:unEY8tjt.net]: すべての例外を把握する必要はない
回復可能かつ回復が要件に含まれるなら個別に処理すべき
それ以外はアスペクトで処理すればいい
267 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 09:04:47.90 ID:nVlZ7k5e.net]: >>247
だからさ、比較できるように例外スタイルで一度きちっと異常系対応して
かつスーパーエレガントなのを書いてくれよって言ってんの
お前のは体よく異常系の処理全無視してるだけじゃん

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

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

最後にもう一度言っておくけどおれは例外を完全否定してるわけじゃねーから
使える場所は限られるって意見ね
268 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 09:07:50.76 ID:nVlZ7k5e.net]: >>262
> 大前提が間違ってる
> 例外なんか最終的にはフレームワークが最上位で纏めてキャッチすりゃいいんだよ

これがど素人の意見
ソフトウェアの品質について考えたことがない
269 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 09:11:48.87 ID:nVlZ7k5e.net]: 「不正な入力です」
「ネットワークでエラーが発生しました」
「書き込みに失敗しました」

こういう情けないダイアログが表示させて終わりのアプリを作るやつね
270 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 09:19:18.64 ID:9okmCQOj.net]: >>269
それでも正常に回復できてるならそれでいいケースは多い
例外の最大の利点は例外安全さえ死守できていればアドホックな例外処理が必須でなくなることで、
より丁寧な処理が必要になれば後から追加すればよい
まあ組み込みとかやってる人には馴染まない考え方だろうね
271 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 09:35:09.59 ID:9okmCQOj.net]: まあC++開発者が未処理例外=クラッシュと短絡的に考えてしまう気持ちはよく分かるよ
呼び出し階層の途中に一つでも if (hoge() != SUCCESS) errorhandle(); があれば例外安全は破綻するわけで、あまりにも非現実的
272 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 09:54:05.98 ID:NbFzEAOW.net]: >>267
仕様は>>218が決めるんだから>>218がコードを提示すべき
>>236みたいに後出しの条件出されても困るからな
273 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 10:02:59.35 ID:+Z2Zhk1G.net]: >>267
> 例外発生場所から遠くなればなるだけ何が原因で例外が発生して、
> その回避はどうすればいいかが不明瞭になっていくってのは
> 散々語られてる例外の欠点
それ戻り値スタイルでも同じだろ

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

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

> 見ればすぐわかるんだから
お前の能力がな w
274 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 12:21:37.48 ID:Di3L4KSP.net]: >>267
例外を使いこなせていないね

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

それと大規模開発をしたことがないのはそちらだろう
関数コールするたびにずらずらと変数や分岐を書かれたらあっという間に管理不能になる
大規模だからこそ標準的なコード、必要十分なコードというのが大切になる
275 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 12:52:23.62 ID:Di3L4KSP.net]: リターンコードスタイルをレビューに出すと袋叩きにされるぞ

・ノイズが多すぎて正常系のレビューが不可能
・同じくどのエラーが上位伝達、エラー変換、共通対応、個別対応なのか見てすぐにわからない
・同じく要件漏れを見落としやすい
・正常系、異常系、判断、伝達などあらゆる要素が密集して強く結合しているため仕様変更があった場合の影響が大きすぎてレビューしきれない
276 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 13:00:29.05 ID:9okmCQOj.net]: >>275
考え方自体には同意するけど、>>271で示したように例外安全が破綻しているケースについてどう考える?
エラーコードを前提にクリーンアップ処理が記述されているコードが混入しているような場合ね
あくまでC++に限った話だけど、大規模開発で完全な例外安全を維持するのは極めて困難だか実際には絵に書いた餅と思ってる
277 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 13:01:15.22 ID:9okmCQOj.net]: >>276
訂正
極めて困難で、実際には絵に描いた餅
278 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 13:05:57.47 ID:eQbQQa6X.net]: レビュアーの経験値不足って感が否めない
279 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 13:14:15.22 ID:NbFzEAOW.net]: >>276-277
必要なら直せばいいだけ
非常に稀な事象についてまで例外安全を遵守する必要はないでしょ
そもそもそういう変なコードが混入してる体質の組織で何を言ってるんだよ？って話だと思うけど
280 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 13:20:41.40 ID:9okmCQOj.net]: >>279
文化と素養の問題だよ
例外の是非でこれだけ荒れる現状を見てれば、例外のスルーなんて怖くてできねえよ
そりゃあんたが全てのコードをレビューしてマサカリ投げまくってくれるなら別だけどねえ
281 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 13:46:08.82 ID:NbFzEAOW.net]: >>280
ごめん、言ってることがよくわからん
そもそも
if (hoge() != SUCCESS) errorhandle();
なんてコードがあったら戻り値スタイルでもどうしようもない
例外は魔法の杖じゃないんだから何でもかんでも例外使えば解決するわけじゃなくて戻り値スタイルより楽にできるというだけの事だよ
プログラムがデカくなるほどその差は開くけど
282 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 15:00:28.97 ID:9okmCQOj.net]: >>281
result = hogehoge();
if (failure(result)) エラー処理();
リソース解放();
これhogehogeが例外起こしたらリークするだろ
283 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 15:09:35.03 ID:NbFzEAOW.net]: >>282
スマートポインタ使うなりcatchしてリソース解放して例外再送出するなりいくらでもやりようはあるだろ…
ちょっとレベル低くね？
284 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 15:25:30.15 ID:9okmCQOj.net]: >>283
だからそれが例外安全だよ
勉強になったね
285 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 15:27:04.68 ID:NbFzEAOW.net]: 流石に恥ずかしくね？ w
286 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 15:51:37.78 ID:GjW/cezm.net]: >>283
基本的にデストラクタやリソース開放系は例外投げられると大変なことになる
catchしてなんて簡単にいってるけどもcatch(...)をそこに入れることになるのはわかるかね
287 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 16:15:33.27 ID:NbFzEAOW.net]: で、そんな当たり前のことを言って何が言いたいの？
聞きかじりの知識を披露してるとしか思えないんだが… w
288 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 18:01:37.80 .net]: 例外機構は宗教
多くの人が正しいと盲信しているに過ぎない
289 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 21:32:31.75 ID:sP4gcHu6.net]: 戻り値でイベント投げるという選択肢がない言語使用自体くそじゃね？
290 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 22:06:05.18 ID:5kYBxhZB.net]: Cにそんな機能あったっけ？
それとも別の言語の信者が折伏に来ているの？
291 名前：デフォルトの名無しさん mailto:sage [2019/01/21(月) 23:00:01.73 ID:vJCo0PxF.net]: >>265
そう、検査例外を正しく使うのはしばしば困難で批判も多いな。ただ、呼び出す処理がどのような
例外を返すか、静的な型検査による保証を与えてくれる仕組みとしては他に無いのも事実。

検査例外を否定するのであれば例外型に頼らない(>>264の後者)か、プログラマの努力で
整合をとってやる(>>261の最後)カウボーイ的プログラミングになる。
>>265はあくまでも例外に型を期待しているようだからカウボーイの方なんだろう。
292 名前： mailto:sage [2019/01/21(月) 23:52:35.55 ID:N0KGcgmj.net]: >>291
＞プログラマの努力で整合をとってやる(>>261の最後)カウボーイ的プログラミングになる。

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

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

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

throw 13;
293 名前：はちみつ餃子 mailto:sage [2019/01/22(火) 02:54:09.24 ID:FdSNzm47.net]: 例外の処理速度については、こういう提案もある。

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

要するに、投げるオブジェクトが条件を満たすときは、
暗黙の返却値のような形で例外を伝播する仕組み。
バイナリレベルの取り扱いも ABI を決めさえすれば済むだろうし、
互換性も確保しやすそうに思う。
294 名前：デフォルトの名無しさん mailto:sage [2019/01/22(火) 07:12:53.52 ID:c7vqWXz4.net]: どう見ても例外否定派の方が宗教がかってる…
295 名前：デフォルトの名無しさん mailto:sage [2019/01/22(火) 08:50:21.38 ID:Z/sMOZE7.net]: 環境の方の質問NGなら完全スルーでお願いします

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

Windows98SE の方に Visual C++ 6.0 & SP6 をインストールしても良いのかも知れませんが
DLL の整合性とか不安
VC++ 2005 は iso 持ってるだけ…Windows98SE で動くバイナリが生成できるとか何とか
296 名前：デフォルトの名無しさん mailto:sage [2019/01/22(火) 09:09:13.74 ID:Z/sMOZE7.net]: 業務で使った経験は一切ないです
使い捨てレベルのものを書くのが目的です
297 名前：デフォルトの名無しさん mailto:sage [2019/01/22(火) 12:47:22.45 ID:beRmTaV+.net]: TEST::TEST()
{
　うんたら
}

ってコンストラスタがあって、このクラスにパラメータ付のコンストラスタを追加したいとき
C# だったら
TEST::TEST(int param) : this()
{
　増やす機能
}
みたいに書きますが C++ の場合はどうやって書きますか
298 名前：デフォルトの名無しさん [2019/01/22(火) 13:28:39.91 ID:/wbMKv3O.net]: TEST::TEST(int param) : クラスのパラメータ(param)
{
　増やす機能
}
299 名前：デフォルトの名無しさん mailto:sage [2019/01/22(火) 14:01:29.45 ID:mZt3aCP3.net]: >>297
委譲コンストラクタでググると出てくると思う。
たしかC++11で追加された機能。
300 名前：はちみつ餃子 mailto:sage [2019/01/22(火) 14:03:25.02 ID:FdSNzm47.net]: >>295-296
LSI-C試食版って Windows 用どころか MS-DOS (16bit) の、しかもスモールモデルしか作れないじゃん。
使い捨ての、いいかげんな富豪的プログラミングしたらすぐメモリ足りなくなるぞ。

ワイとしては Open Watcom C++ を推すやで。
301 名前：デフォルトの名無しさん [2019/01/22(火) 14:11:32.02 ID:/wbMKv3O.net]: >>295
https://bellard.org/tcc/
https://en.wikipedia.org/wiki/Tiny_C_Compiler
https://dyama.org/2012/11/tiny-c-compiler/
https://github.com/TinyCC/tinycc
302 名前：デフォルトの名無しさん mailto:sage [2019/01/22(火) 15:51:04.50 ID:DsO4NZlu.net]: LSI-Cとかなっつｗ
昔の勉強用コンパイラといったらこれだったな

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

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