C++相談室 part141

■ このスレッドは過去ログ倉庫に格納されています
2019/02/22(金) 03:07:43.52ID:MgOIx7iK
次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part137 (正しくはpart138)
http://mevius.5ch.net/test/read.cgi/tech/1535353320/
C++相談室 part139
https://mevius.5ch.net/test/read.cgi/tech/1538755188/
C++相談室 part140
https://mevius.5ch.net/test/read.cgi/tech/1547326582/

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.103【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1530384293/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

----- テンプレ ここまで -----
-
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured
2019/03/12(火) 23:14:38.07ID:JuWddRAo
>>296,297
アホか、何がマウントだボケ
自分で試しもせずに2chに丸投げとか普通にダメだろ

>>298
iterator_traitsに与える型の要件(だけでいいかどうかはさておき)を満たすなら特殊化なんかいらんでしょ
リファレンス見る限り、iterator_traitsの特殊化はポインタのためだけにあると思う
302デフォルトの名無しさん
垢版 |
2019/03/12(火) 23:27:20.69ID:Zu3OGTTs
>>300
どの本もそういう書き方になってるんだけど、その理由がわからない。
>>293は呼び出し方によっていろいろ問題が起きるんだけど、その理由がわからなさすぎる。
その辺がスッキリわかる本はないですかね。
2019/03/12(火) 23:39:14.10ID:YKaKEG7g
本は知らん
SFINAEが使えるのは宣言部分
そこで置換失敗すると宣言そのものが無かったことになる
2019/03/13(水) 12:04:15.67ID:lxBl+sTZ
>>297
マウントが取りたいだけで教える知識がないだけやねんｗ
2019/03/13(水) 12:37:00.35ID:mh4jyrHE
そう
分からない質問には自分で試せ
これがC++使ってる奴の特徴
2019/03/13(水) 12:47:27.60ID:QLyGxm6u
>>304,>>305
そう思うなら自分が教えてやれば？
2019/03/13(水) 20:50:37.56ID:u/DrurAb
規約はあるけど「実装が規約」をやっちゃってる部分が多くて、
しかもコンパイラのバージョン依存がひどいってのがc++だからな。
規約は語れても実際にどう動作するか語れない輩も多いだろうね。
2019/03/13(水) 21:07:13.50ID:QLyGxm6u
そういう構図じゃないと思うよ
309デフォルトの名無しさん
垢版 |
2019/03/13(水) 21:25:53.81ID:Z/ka/TFK
どなたか iostreamの存在価値について熱く語ってくれないか。
2019/03/13(水) 21:34:23.99ID:VRJ3bLEu
いやだ
2019/03/13(水) 21:38:23.77ID:xQTh8hgU
>>309
https://www.google.com/search?q=%22iostream%E3%81%AE%E4%BE%A1%E5%80%A4%22
312デフォルトの名無しさん
垢版 |
2019/03/13(水) 21:55:23.80ID:780qHyAl
VS2019って4月2日に出るのかな？
2019/03/13(水) 22:19:08.88ID:DKlmxwmb
米国時間4/2にローンチイベント行ってるから日本だと3日かな
2019/03/13(水) 22:44:27.53ID:mh4jyrHE
>>306
だから分からないのにマウント取るのやめたら？
315290=301
垢版 |
2019/03/13(水) 23:05:00.60ID:QLyGxm6u
>>314
バカだろお前

ID:Zu3OGTTsはSFINAEでググれと言われてSFINAEは知ってると言ったろ
その上で>>302の書き込み見ておかしいと思わんのか？
それに>>300で答えは出てるだろうが

> だから分からないのにマウント取るのやめたら？
お前のことだよ
316デフォルトの名無しさん
垢版 |
2019/03/14(木) 18:41:51.50ID:qKfDR5xc
>>313
待ちどおしいね。
317デフォルトの名無しさん
垢版 |
2019/03/14(木) 20:57:09.31ID:HZIDFMYl
このスレの住人は、新しいVisual Studioでどんなことに期待してるの？
2019/03/14(木) 20:58:50.91ID:30TndOaO
>>317
マウントされないこと
2019/03/14(木) 21:00:03.79ID:O0o087YX
仕様通りに動いてくれりゃそれでいいわ。
2019/03/14(木) 21:20:35.00ID:nuZulfE1
C++20の早期対応
2019/03/14(木) 21:25:28.09ID:xC4JJLNw
clang対応
2019/03/14(木) 21:29:12.31ID:vJRyyCPl
C#での使い勝手向上
2019/03/14(木) 21:36:15.68ID:r+Z4K3kn
フロントエンドをVSCodeにしてくれ
2019/03/14(木) 21:45:44.62ID:rlbQlqp5
メモリ喰わずに軽くなって…
325デフォルトの名無しさん
垢版 |
2019/03/14(木) 22:54:08.60ID:qKfDR5xc
何個まで願い事聞いてくれるんだろ。
2019/03/14(木) 23:13:56.40ID:3EvgP48J
>>317
Expressを出してくれ
2019/03/14(木) 23:19:01.48ID:NTAm4EVS
>>317
MFC…
2019/03/15(金) 06:01:20.22ID:qA/WFgyI
Windows formsのC++へ移植してmfcを完全に抹消してくれ
2019/03/15(金) 06:06:32.23ID:nvk7uoI+
>>317
オープンソース化
2019/03/15(金) 08:11:25.59ID:2KXTO6ja
本当によくかけとるわ。
この人たちで標準委員やったほうがいいんじゃないかと思う。
https://ttsuki.github.io/styleguide/cppguide.ja.html
2019/03/15(金) 08:17:17.58ID:qA/WFgyI
ゴミ
2019/03/15(金) 08:54:09.40ID:fLDhqMRG
けっこう癖が強いよね。例外やpimpl否定したり。
2019/03/15(金) 08:57:01.66ID:LNWMUSed
危険思想だなｗ
ヤバすぎてヘドが出るｗ
2019/03/15(金) 09:06:08.50ID:Uugk/tx2
まあでかいプロジェクトはこんなもんだろう。
例外は実際よくないと思うわ。
2019/03/15(金) 09:48:31.74ID:Af9j6Fb3
pimpl否定ってあったっけ？
うちのプロジェクトも原則例外禁止
むかしは一律禁止だったけど
2019/03/15(金) 11:11:39.02ID:t9j+keaC
>>330
古くさいって言われてなかった？
2019/03/15(金) 11:55:34.06ID:E1i6RSEf
googleのスタイルガイドは和訳が古くて英語版しか読まなくなって何年にもなるが追いついてるのか？
2019/03/15(金) 12:05:48.86ID:PdhXv0FK
例外無しとか小規模の組み込み以外で意味あるのかね？
2019/03/15(金) 12:37:29.90ID:hyh/CKnF
例外使った時点で疎結合もへったくれもなくなると思うわ。
能力的に幅のあるプロジェクトで使うには難しいよ。
2019/03/15(金) 12:56:39.19ID:ng8+eCdq
>>339
> 能力的に幅のあるプロジェクトで使うには難しいよ。
これには同意するけど

> 例外使った時点で疎結合もへったくれもなくなると思うわ。
意味不明
例外以外の方法使っても似たようなことをする羽目になるだけ
なら意図が明確な例外のほうがマシ
2019/03/15(金) 14:16:54.97ID:9vyMIRpZ
戻り値なら呼び出し元と呼び出し先の間の結合だけだが、例外はよりコールスタックの根本の方へ結合が及ぶことがある
フレームワークのように、例外を使ってあえて中間をすっ飛ばしてコールスタックの上と下を結合させるケースもあるけどね
2019/03/15(金) 14:19:06.67ID:9vyMIRpZ
念の為補足するけど、Javaの検査例外みたいに常に直上での例外処理を強制するスタイルは戻り値と事実上等価だからここでは論外ね
2019/03/15(金) 14:31:16.21ID:yhzlHwio
つまり標準ライブラリのほとんどを使うなと言うこと？
2019/03/15(金) 14:37:11.61ID:yhzlHwio
そもそも例外使った方が疎結合になるだろうに
2019/03/15(金) 16:00:22.80ID:q2a9nFaz
他の言語や過去の (例外をあまり想定していない) システムと接続することもあるし、
そういう全体のエコシステムを考えると例外がかえって面倒ということはあると思う。

C++ だけの (新規の) プロジェクトなら全く例外を使わないというのは極端なスタイルだと思うが。
2019/03/15(金) 16:32:10.73ID:SB/vZ5dO
例外があると、それが理由で上下の階層が深いシステムになりがちだと思うよ。
節度があれば正直なんでもいいが、言語的にクソ設計を許さないのならその方がありがたい。
2019/03/15(金) 16:54:37.47ID:oq4eakC3
c++じゃないところからc++のコード呼び出すなら例外外に出さないようにtry catchでラップするだけだし
逆で途中のコードが例外発生したために解放処理が飛ばされるってなら、raiiクラス化しろって話にならね？

通信経路でやり取りするなら相手が例外処理で実装されていようがされていなかろうがなんの関係もないし
2019/03/15(金) 17:57:31.19ID:BCAT3j7k
>>347
要は、メッセージングが至高ってことだな
349デフォルトの名無しさん
垢版 |
2019/03/15(金) 18:59:44.81ID:0PFucV7H
つまりJavaが至高。
2019/03/15(金) 20:05:35.24ID:LNWMUSed
例外だしてどーすんの
ミッションクリティカルで直せるの？
意味ないじゃん

例外使いたきゃ専用言語使えばいい
2019/03/15(金) 20:09:02.33ID:qA/WFgyI
プログラミング言語の専門家に聞いて
2019/03/15(金) 20:37:29.42ID:ng8+eCdq
>>345
> 他の言語や過去の (例外をあまり想定していない) システムと接続することもあるし、
> そういう全体のエコシステムを考えると例外がかえって面倒ということはあると思う。
もうそういう極端な例でしか反論できないことはわかったよw
2019/03/15(金) 20:59:33.43ID:UMZlK7qa
江添勝てなかったか・・
2019/03/15(金) 21:09:50.31ID:2KXTO6ja
>>336
微妙に修正はされてる。
てかクソなc++本読むよりかよっぽど各機能の利点、問題点が簡潔に書けてると思うが。
2019/03/15(金) 21:13:26.14ID:BCAT3j7k
まだひっくり返る可能性はあると思うね
2019/03/15(金) 21:50:38.17ID:fLDhqMRG
>>335
pimplに限った話じゃないけど、前方宣言とそれによる定義の隠蔽が推奨されていない。
2019/03/15(金) 22:07:25.54ID:qA/WFgyI
Googleはな
2019/03/15(金) 22:38:20.91ID:4qwaELjT
>>338
大規模なところでも例外禁止あるから
mozillaもそうでしょ
AAAなゲームスタジオでも多い
性能引き出したかったらそういう厳しい制約がいるんだよ
2019/03/15(金) 22:40:04.57ID:q2a9nFaz
>>352
グーグルのガイドラインが極端なのは当たり前だ。
超巨大なエコシステムで成り立ってるわけだし。
例外を使わない派がしばしばグーグルのガイドラインを持ち出すんだけど、
そのガイドラインにすら、最初から設計してたら違ったかもしれないという
文言があるので、 C++ を使った設計理念一般としての強い根拠にならんのよな。

私としては、一般的な C++ での設計の参考にするべきは標準ライブラリだと思う。
標準ライブラリはその言語の思想をよりはっきりと体現するものだし、
それに沿って作ったものは連携しやすくもある。
(昔からあるライブラリの一部は変な個所もあるが。)

>>346
C++ はクソ設計でもどうにか形には出来るっていう方向性だと思う。
まともな設計ならそれが一番良いにきまってるけど、
それが期待できない場合が大半だという現実がある。
360KAC
垢版 |
2019/03/15(金) 22:48:06.41ID:rqfh3/aR
例外禁止とかの環境って、
newの失敗とか毎回チェックするの？
2019/03/15(金) 22:54:50.21ID:2KXTO6ja
規約を守る守らんってことにしか目がいかんのな。
やっぱ馬鹿ばっかだわ。
2019/03/15(金) 22:54:57.62ID:12ZNVc6t
>>360
newの失敗のチェックって何するの？
null返ったかどうかのチェック？
2019/03/15(金) 23:03:42.33ID:L+hp7qbL
例外処理機構が無かったら、メモリ確保に失敗しても、
そこから過去のロールバックができない

自己流で、long jump するぐらいなら、例外処理の方がよい
2019/03/15(金) 23:09:45.82ID:12ZNVc6t
>>363
いや、失敗したら駄目だろ。失敗しないのが正しい。
プログラミング言語如きが考慮すべき問題ではない。
2019/03/15(金) 23:18:26.60ID:fLDhqMRG
>>363
そのロールバックってのはCとmallocじゃできないようなものなのかな。
2019/03/15(金) 23:25:12.09ID:qA/WFgyI
new失敗とかコンピュータが壊れてるからチェックしても意味ない
2019/03/15(金) 23:27:22.88ID:qA/WFgyI
当然特殊なケースは除くからな
一応言っておかないと組み込みガー君とか宇宙線でエラーガー君が飛んでくるからな
2019/03/15(金) 23:37:27.23ID:WyRx2/31
>>359
＞私としては、一般的な C++ での設計の参考にするべきは標準ライブラリだと思う。
設計ではなく使い方の参考に、という意味では賛成だけど
テンプレートバリバリの設計はあまりにもコストがかかるというのを知っといて欲しい
ああいうのは湯水のごとく時間をかけられるからやれるんであって
2019/03/15(金) 23:38:17.19ID:iTKvW/zw
きみらはあれか、元記事とか全然読まずにコメントするクチか
リンク元には「例外は全く新規のプロジェクトならデメリットよりメリットが優先するので使って良い。
ただ既存のグーグルプロジェクトは元々例外を想定していないのでこれに例外のパターンを導入する
とリスクのほうが多いのでやめるべき。ただし Windows については例外がある(駄洒落ではない)」
と書いてあるんだがちゃんと読んだか。ちなみに駄洒落ではない、は俺が追加したのでなく元の文にある
2019/03/15(金) 23:45:56.39ID:q2a9nFaz
>>368
そんな極端な意味では言ってない。
手間が合理的な範囲内で「参考」には出来るよって程度の話。
2019/03/15(金) 23:48:42.07ID:5dVML2o5
エラーにはリカバリーすべきものとそうでないものがある
あとそのエラーが起こる頻度の違い

リカバリーしないものはその時点で即死するのが正しい
リカバリーするものでかつエラーが普通に起こるものはエラーコードで処理するのが正しい

となると残りのリカバリーするものでかつたまにエラーがおこるようなのが例外にする価値があるエラー
あと例外発生時のunwindが重いからそれでも問題にならないもの
となるとあんまり使えるとこないんだよね
そういうわけで最近例外なしの言語がでてきてる流れなんだろう
372KAC
垢版 |
2019/03/15(金) 23:51:56.30ID:rqfh3/aR
>>366
コンピュータが壊れない限りメモリ確保が失敗しない環境って凄いな。。。
2019/03/15(金) 23:54:45.92ID:qA/WFgyI
出、出〜ｗｗｗ
一名いらっしゃいましたｗｗｗ
2019/03/16(土) 00:07:16.61ID:HR8X4dmV
例外ってcatchしなきゃ投げたその場で落ちてくれるのがこの上なく便利だろう
問題残したまま実行続けて別の関係ないところで落ちるのが最悪
runtimeで落ちて困るような用途でも、
ソースコードあるやつなら静的解析で例外発生箇所網羅出来そうなものだが
網羅できればリソースリークする危険な場所わかるし、対処も出来るのにね

逆にソースコード無いライブラリやダイナミックリンクする奴は、例外含めて外部仕様としてかっちり決まっているべきものじゃね
2019/03/16(土) 00:11:00.29ID:oXtW8C30
>>374
> 例外ってcatchしなきゃ投げたその場で落ちてくれるのがこの上なく便利だろう

その場じゃなくstackが全部巻き戻ってからでしょ
2019/03/16(土) 00:15:00.35ID:U94TV9G4
>逆にソースコード無いライブラリやダイナミックリンクする奴は、例外含めて外部仕様としてかっちり決まっているべきものじゃね
んなもんコンテナで隔離する以外使い道ねーわ。
2019/03/16(土) 00:18:04.69ID:HR8X4dmV
>>376
仕様ってのは例外外に出すか出さないか、
出すなら出し得る例外の種類のリスト
出さないならエラー毎にエラーコードやら返し方やら決めるって話
2019/03/16(土) 00:23:45.45ID:oXtW8C30
そうなんだよね
例外の仕組みわかってないやつは平気で動的ライブラリの界面に
例外使ったりするんだよね
あと標準ライブラリ丸出しにするやつもしかり
それ誰も互換性保証してねーから
379デフォルトの名無しさん
垢版 |
2019/03/16(土) 00:24:47.11ID:UXq90ll9
>>376
核戦争を生き抜くには。
2019/03/16(土) 00:24:57.90ID:HR8X4dmV
まあ標準ライブラリの例外の使い方のおかしさも気になるが

std::stoiで例外投げるバージョンしか無い上に何故かlogic_error扱いのinvalid_argumentやout_of_range投げる

いや、これ出る状況普通runtime_errorだよね
2019/03/16(土) 00:29:24.58ID:cz3ooqCT
>例外含めて外部仕様としてかっちり決まっているべきものじゃね

そこを言語の機構で保証できない、動的言語みたいななあなあ状態なのが残念なところだね。
それをきっちり保証しようとした検査例外はそれはそれで扱いづらいところがあるし。
2019/03/16(土) 00:29:25.98ID:U4afEAjj
>>371
リカバリーするかしないか、頻度が高いか低いか、どちらもプログラム（特にライブラリ）を書いてる時点では
言い切れないから困るんですよねぇ。
383デフォルトの名無しさん
垢版 |
2019/03/16(土) 00:36:35.46ID:UXq90ll9
そこでプロパティ型なんですよ。
2019/03/16(土) 06:11:19.71ID:7Yfqh0Zg
>>372
無限にnewできる理想郷に住んでるんだろw
相手しなくていいよ
385デフォルトの名無しさん
垢版 |
2019/03/16(土) 06:46:32.47ID:TLiwIm0H
復旧不可能な例外もあれば、些細な例外もあるよね。
戻り値チェックで十分でしょと思うようなところで例外を投げるJava/C#みたいな流儀だと、いちいちキャッチするのが面倒。
386デフォルトの名無しさん
垢版 |
2019/03/16(土) 06:52:39.99ID:TLiwIm0H
Cでは戻り値で判定できたはずのエラー種別が例外クラスで細かく分類されてしまったことで、
エラー処理で書かなければならないコード量が増えて例外のキャッチ漏れまで起きる危険性が生み出された。
2019/03/16(土) 07:31:06.00ID:5/K53Ire
その程度の知識で語ってる奴は戻り値方式でも処理漏れするだろw
2019/03/16(土) 07:35:15.72ID:/kg6KhNe
例外の嫌なところは
処理できない案件を低水準側に丸投げするところなんだよな…

ユニックスのプロセスの死亡順序もそうだが、
計算機業界は常識が逆転してゐる…
2019/03/16(土) 07:38:02.24ID:/kg6KhNe
というわけでおそらくアプリの設計ｼﾁｭの99%ぐらいは
　例外発生＝プログラムの死亡
、とみなして良いはず
ここまで割り切るならはじめて例外はお手軽で便利と言える
390デフォルトの名無しさん
垢版 |
2019/03/16(土) 12:28:02.50ID:UXq90ll9
例外をキャッチしたらプランBに移行するのが、真の戦闘のプロ。
2019/03/16(土) 12:49:25.73ID:V15J7n/y
例外なんてグローバル変数みたいなもの。
だから低レイヤで使うのは仕方ない
2019/03/16(土) 12:50:47.84ID:jRc2/nMs
std::cin >> a;

は入力を延々と待っている。
これ別スレッドから止めさせる方法はありますか？
2019/03/16(土) 13:10:50.41ID:V15J7n/y
stdin閉じるとどうなる？
2019/03/16(土) 15:40:22.15ID:/kg6KhNe
（組み込みはともかくアプリの場合は呼び出し元の方が高水準レイヤにあたるのではないかというツッコミが来ると思ったが
　来なかったので黙っていよう…
2019/03/16(土) 17:27:11.59ID:/kg6KhNe
>>390
プランBったって、プログラム起動時にあらかじめmallocしておいた何キロバイトかをfreeして
ダイアログを出して[OK]で終了、ぐらいなんじゃ…
2019/03/16(土) 19:15:22.19ID:zOgp3uDK
>>388
いや、プログラムでは、呼び出し側の方が高レベル、呼び出された側が低レベル
なので、呼び出された側が例外を投げた場合、高レベル側の関数で処理できる
ので適切。
397デフォルトの名無しさん
垢版 |
2019/03/16(土) 20:00:47.57ID:TLiwIm0H
多くの例外の基底クラスになる exception にエラーコード整数値を出力する関数があればもう少しC寄りのエラー処理ができたと思うのだが。
既存のexceptionメンバ関数 const char *what() だけでは扱いが困難。
398デフォルトの名無しさん
垢版 |
2019/03/16(土) 20:14:28.85ID:1JRLHvWf
std:::to_string();
2019/03/16(土) 20:14:39.74ID:w9XKSp7E
>>397
必要ならそういうクラスを定義するだけだろ
2019/03/16(土) 20:15:00.26ID:1JRLHvWf
sage
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。