【初心者歓迎】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/ 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とかなっつｗ 昔の勉強用コンパイラといったらこれだったな 303 名前：デフォルトの名無しさん mailto:sage [2019/01/22(火) 16:10:30.87 ID:3oaAhSoC.net] LS愛ちゃん 304 名前：はちみつ餃子 mailto:sage [2019/01/22(火) 16:47:15.38 ID:FdSNzm47.net] >>302 Cマガの付録CDに常に収録されてたよな！ 305 名前：デフォルトの名無しさん [2019/01/22(火) 17:01:23.17 ID:8l7UUA+M.net] LatticeCとかBDS-Cとか使ってたわ 306 名前：デフォルトの名無しさん mailto:sage [2019/01/22(火) 17:22:22.39 ID:beRmTaV+.net] >>298-299 TEST::TEST(int param) : TEST() { 　増やす機能 } で出来ました。ありがとうございました。 307 名前：デフォルトの名無しさん mailto:sage [2019/01/22(火) 18:21:52.81 ID:Z/sMOZE7.net] bcc32c でコンパイルしたバイナリが Win98SE 上で動くことを確認… Win98SE 上だと Turbo C が動くことを確認… Open Watcom C++ というのは存じませんでした 確認してみます 308 名前：デフォルトの名無しさん mailto:sage [2019/01/22(火) 18:30:45.76 ID:hELj0NVW.net] 森公一郎さん、4年前に亡くなってる 309 名前：デフォルトの名無しさん mailto:sage [2019/01/22(火) 18:51:51.72 ID:c7vqWXz4.net] >>295 > VC++ 2005 は iso 持ってるだけ…Windows98SE で動くバイナリが生成できるとか何とか なんで試さんの？ 310 名前：デフォルトの名無しさん mailto:sage [2019/01/22(火) 20:54:28.21 ID:Z/sMOZE7.net] DLL hell に躊躇 311 名前：デフォルトの名無しさん mailto:sage [2019/01/22(火) 23:43:17.99 ID:f8uEJHYw.net] LSI-C試食版ｗｗｗ 懐かしいなあ あの頃はものすごくCPU遅かったよね 486にして感激したからな もうC言語でプログラムはしたくない C++だ・・・ 312 名前：デフォルトの名無しさん mailto:sage [2019/01/23(水) 03:50:30.92 ID:2NaZdHzA.net] コメントに//が使えない時点でもうダメだな俺はw 313 名前：デフォルトの名無しさん mailto:sage [2019/01/23(水) 06:49:23.93 ID:u7DJzLvn.net] 古いOSでも動作させたいけど、ソースは新しい規格で書きたい、 と言うのは要望としてはありうるな。 >>295 はLSI-C試食版(C89相当だっけ?)を使ってるようだから、 そのクチではないのかも知れんけど。 314 名前：デフォルトの名無しさん mailto:sage [2019/01/23(水) 07:14:34.51 ID:aGw/aeEH.net] >>310 今時なら仮想マシンでやればいいだけだろ 315 名前：デフォルトの名無しさん mailto:sage [2019/01/23(水) 08:57:06.72 ID:A4LjhfFf.net] >>312 コメント前に // つけるより /* コメント */ あるいは #if 0 コメント #endif のほうがすっきりしないか？ 316 名前：315 mailto:sage [2019/01/23(水) 08:57:45.81 ID:A4LjhfFf.net] コメントが複数行にわたる前提ね 317 名前：デフォルトの名無しさん mailto:sage [2019/01/23(水) 09:18:31.94 ID:NxchbiGL.net] だから何？ それに同意しようがしまいが単一行コメントのときに面倒なのは変わらないよね 個人的にはエディタがコメントの一括付け外しに対応してるなら複数行でも//の方が見やすいと思ってるけど 318 名前：デフォルトの名無しさん mailto:sage [2019/01/23(水) 09:36:35.20 ID:WSWjtujW.net] C言語の a=b;　って アセンブラで言うと、メモリ→レジスタ→メモリって移し替えてるのと同じ？ メモリ→メモリにデータコピーする時って、必ずレジスタを経由しないとだめなのかな？ アセンブラ勉強初めたばっかで何言ってんだこいつ的な感じだったらごめん。 319 名前：はちみつ餃子 mailto:sage [2019/01/23(水) 10:06:54.98 ID:+T2/7smM.net] >>318 CPU の種類による。 アセンブラはアセンブラという言語の規格があるわけではなくて、 各コンピュータの機械語の単語を便宜的に読みやすい書式に置き換えた ものの総称なので、使える命令は各アーキテクチャのデザインに従うし、 書式のバリエーションもある。 いくつかの伝統的な習慣はあるけれど。 データの移送にレジスタを経由しなければならないようなデザインの CPU もあるし、 そうでないものもある。 メモリアクセスをする命令とその他演算の命令を明確に分離するようなデザインの アーキテクチャを特に Load?store architecture と呼んでる。 https://en.wikipedia.org/wiki/Load%E2%80%93store_architecture コンピュータの設計の根本を左右する方針の違いなので、 理解があやふやとはいえ、ここに引っかかりを感じたというのは才能を感じる。 320 名前：デフォルトの名無しさん mailto:sage [2019/01/23(水) 15:54:30.09 ID:WSWjtujW.net] >>319 自分が勉強してたCPUがたまたまレジスタ必要とするものだったということですね。ありがとうございます。 あと、intelとryzenは、どちらのCPUであっても殆どのソフトは動作しますが この2つのCPUのアーキテクチャオペランドは同じということでしょうか？ ゲームなんかは高速化の部分でアセンブラ使う場所も頻繁にあるんじゃないかなと思うのですが。 321 名前：デフォルトの名無しさん mailto:sage [2019/01/23(水) 16:07:56.74 ID:WSWjtujW.net] すみません自己解決。 x64ですね。 322 名前：デフォルトの名無しさん mailto:sage [2019/01/23(水) 22:57:36.31 ID:A4LjhfFf.net] >>317 wwww 逆に、だから何？ エディタが/* 入力と同時に */ を自動挿入してくれるなら全く変わらないだろ それともおまえのエディタは / 入力で もひとつ/ を自動挿入するように設定でもしてるのか？ ゆとりもここまで来るとどーしよーもねーな。 323 名前：デフォルトの名無しさん mailto:sage [2019/01/23(水) 23:18:56.27 ID:A4LjhfFf.net] >>318 >>319 状況によるが、 a = b; はメモリを介せず、できるだけレジスタ間コピーになるように最適化される。 んでメモリ to メモリを許すのはCISCと相場が決まってる RISCはメモリ to メモリは命令にない 。命令セットを減らしてるからこそ reduce このおかげで回路が簡単になり、所用クロック数をほぼ等しくして、クロック(Hz)をあげることができた。 このタイプはメモリ→レジスタ→メモリとせざるを得ない 今は、パイプラインを深くして、CISCでもクロックをあげられるようになったのでRISC/CISCはあんまり関係なくなった。 CICSの代表はx86なのでメモリ→メモリ命令セット調べてみ。 CISCの歴史的な経緯がわかるのは、これもCISC代表のx68kやH8は、命令セットごとに大幅に所用クロック数が違う。 それに対してx86の流れをくむ最新設計のRL78だとほとんどの命令セットが1クロックとなって。RISCと変わらない上に、 メモリ to メモリが可能となってる。それでも メモリ to レジスタに比べて1クロック増えてる。 メモリ to メモリ とレジスタ to メモリを同クロック数で実行しようとするなら、 バスラインがもう一組(例えば32bit)必要になった上に、 2ポートメモリが必要になってしまうwwww 324 名前：デフォルトの名無しさん mailto:sage [2019/01/23(水) 23:20:08.21 ID:A4LjhfFf.net] アンカー違い × >>319 ○ >>320 325 名前：デフォルトの名無しさん mailto:sage [2019/01/23(水) 23:21:30.54 ID:MK/3pF0O.net] >>322 自分で複数行が前提だと言っときながら何言ってんの君 326 名前：デフォルトの名無しさん mailto:sage [2019/01/24(木) 00:07:57.67 ID:sZmPY6bv.net] >>325 */の自動補完は複数行だろうが単一行だろうが関係ないだろが。 おまえがエディタ支援による入力補助を持ち出したから応じてやっただけだろゆとり 入力の手間はむしろ/* */の方が楽なんだよお馬鹿さん 327 名前：デフォルトの名無しさん mailto:sage [2019/01/24(木) 00:17:17.17 ID:sZmPY6bv.net] >>325 それとさ俺が複数行限定といってるのに >>317 >単一行コメントのときに面倒なのは変わらないよね また単一行の話をしてるのはそっちだろーが。 おまえは朝鮮人か？それともボケてんのか？ 328 名前：はちみつ餃子 mailto:sage [2019/01/25(金) 04:31:55.12 ID:D9LdM3uI.net] まあ例えばインテルアーキテクチャでも、 機械語の命令列を内部で μop に分解して最適化してから実行したりするので、 機械語のレベルなんてまだまだ高級な層。 内側では RISC 的なデザインとも融合していて 正直言って、そこで何が起きているのか正確に理解するのは無理。 (結果に影響しない範囲で) 命令を並べ替えることすらあり、 しかし、マルチスレッドと絡むとわけわかんなくなりがち。 Z80 の牧歌的な世界を知ってると隔世の感がある。 実際、演算能力で言えば何百倍とか何千倍とかいう規模で違うもんな…… 329 名前：デフォルトの名無しさん mailto:sage [2019/01/25(金) 04:48:14.16 ID:RBnOR415.net] Z80Aで、おおむね4Mhzだったような 無印Z80は知らない 日本人だとZ80AよりμPD870Cの方が普及？？？ 330 名前：デフォルトの名無しさん mailto:sage [2019/01/25(金) 05:29:09.86 ID:VVNAHEZ9.net] >>329 μPD780C-1な。870だと電卓チップになってしまう。 詰めが甘いな :-P 331 名前：デフォルトの名無しさん mailto:sage [2019/01/25(金) 09:28:14.11 ID:U8XeH6tm.net] >>328 自分もこの結論に達した

---

---

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

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