【初心者歓迎】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/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

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

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

TEST::TEST()
{
　うんたら
}

ってコンストラスタがあって、このクラスにパラメータ付のコンストラスタを追加したいとき
C# だったら
TEST::TEST(int param) : this()
{
　増やす機能
}
みたいに書きますが C++ の場合はどうやって書きますか

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

TEST::TEST(int param) : クラスのパラメータ(param)
{
　増やす機能
}

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

>>297
委譲コンストラクタでググると出てくると思う。
たしかC++11で追加された機能。

**はちみつ餃子** ◆8X2XSCHEME · 2019/01/22(火) 14:03:25.02

>>295-296
LSI-C試食版って Windows 用どころか MS-DOS (16bit) の、しかもスモールモデルしか作れないじゃん。
使い捨ての、いいかげんな富豪的プログラミングしたらすぐメモリ足りなくなるぞ。

ワイとしては Open Watcom C++ を推すやで。

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

>>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

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

LSI-Cとかなっつｗ
昔の勉強用コンパイラといったらこれだったな

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

LS愛ちゃん

**はちみつ餃子** ◆8X2XSCHEME · 2019/01/22(火) 16:47:15.38

>>302
Cマガの付録CDに常に収録されてたよな！

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

LatticeCとかBDS-Cとか使ってたわ

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

>>298-299

TEST::TEST(int param) : TEST()
{
　増やす機能
}

で出来ました。ありがとうございました。

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

bcc32c でコンパイルしたバイナリが Win98SE 上で動くことを確認…
Win98SE 上だと Turbo C が動くことを確認…

Open Watcom C++ というのは存じませんでした
確認してみます

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

森公一郎さん、4年前に亡くなってる

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

>>295
> VC++ 2005 は iso 持ってるだけ…Windows98SE で動くバイナリが生成できるとか何とか
なんで試さんの？

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

DLL hell に躊躇

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

LSI-C試食版ｗｗｗ
懐かしいなあ
あの頃はものすごくCPU遅かったよね
486にして感激したからな
もうC言語でプログラムはしたくない
C++だ・・・

**デフォルトの名無しさん** · 2019/01/23(水) 03:50:30.92

コメントに//が使えない時点でもうダメだな俺はw

**デフォルトの名無しさん** · 2019/01/23(水) 06:49:23.93

古いOSでも動作させたいけど、ソースは新しい規格で書きたい、
と言うのは要望としてはありうるな。

>>295 はLSI-C試食版(C89相当だっけ?)を使ってるようだから、
そのクチではないのかも知れんけど。

**デフォルトの名無しさん** · 2019/01/23(水) 07:14:34.51

>>310
今時なら仮想マシンでやればいいだけだろ

**デフォルトの名無しさん** · 2019/01/23(水) 08:57:06.72

>>312
コメント前に // つけるより
/*
コメント
*/

あるいは

#if 0
コメント
#endif

のほうがすっきりしないか？

**315** · 2019/01/23(水) 08:57:45.81

コメントが複数行にわたる前提ね

**デフォルトの名無しさん** · 2019/01/23(水) 09:18:31.94

だから何？
それに同意しようがしまいが単一行コメントのときに面倒なのは変わらないよね
個人的にはエディタがコメントの一括付け外しに対応してるなら複数行でも//の方が見やすいと思ってるけど

**デフォルトの名無しさん** · 2019/01/23(水) 09:36:35.20

C言語の a=b;　って
アセンブラで言うと、メモリ→レジスタ→メモリって移し替えてるのと同じ？
メモリ→メモリにデータコピーする時って、必ずレジスタを経由しないとだめなのかな？
アセンブラ勉強初めたばっかで何言ってんだこいつ的な感じだったらごめん。

**はちみつ餃子** ◆8X2XSCHEME · 2019/01/23(水) 10:06:54.98

>>318
CPU の種類による。

アセンブラはアセンブラという言語の規格があるわけではなくて、
各コンピュータの機械語の単語を便宜的に読みやすい書式に置き換えた
ものの総称なので、使える命令は各アーキテクチャのデザインに従うし、
書式のバリエーションもある。いくつかの伝統的な習慣はあるけれど。

データの移送にレジスタを経由しなければならないようなデザインの CPU もあるし、
そうでないものもある。
メモリアクセスをする命令とその他演算の命令を明確に分離するようなデザインの
アーキテクチャを特に Load?store architecture と呼んでる。

https://en.wikipedia.org/wiki/Load%E2%80%93store_architecture

コンピュータの設計の根本を左右する方針の違いなので、
理解があやふやとはいえ、ここに引っかかりを感じたというのは才能を感じる。

**デフォルトの名無しさん** · 2019/01/23(水) 15:54:30.09

>>319
自分が勉強してたCPUがたまたまレジスタ必要とするものだったということですね。ありがとうございます。

あと、intelとryzenは、どちらのCPUであっても殆どのソフトは動作しますが
この2つのCPUのアーキテクチャオペランドは同じということでしょうか？
ゲームなんかは高速化の部分でアセンブラ使う場所も頻繁にあるんじゃないかなと思うのですが。

**デフォルトの名無しさん** · 2019/01/23(水) 16:07:56.74

すみません自己解決。
x64ですね。

**デフォルトの名無しさん** · 2019/01/23(水) 22:57:36.31

>>317
wwww
逆に、だから何？
エディタが/* 入力と同時に
*/ を自動挿入してくれるなら全く変わらないだろ
それともおまえのエディタは / 入力で
もひとつ/ を自動挿入するように設定でもしてるのか？
ゆとりもここまで来るとどーしよーもねーな。