C++相談室 part141

**デフォルトの名無しさん** · 2019/02/22(金) 03:07:43.52

次スレを立てる時は本文の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/15(金) 14:19:06.67

念の為補足するけど、Javaの検査例外みたいに常に直上での例外処理を強制するスタイルは戻り値と事実上等価だからここでは論外ね

**デフォルトの名無しさん** · 2019/03/15(金) 14:31:16.21

つまり標準ライブラリのほとんどを使うなと言うこと？

**デフォルトの名無しさん** · 2019/03/15(金) 14:37:11.61

そもそも例外使った方が疎結合になるだろうに

**はちみつ餃子** ◆8X2XSCHEME · 2019/03/15(金) 16:00:22.80

他の言語や過去の (例外をあまり想定していない) システムと接続することもあるし、
そういう全体のエコシステムを考えると例外がかえって面倒ということはあると思う。

C++ だけの (新規の) プロジェクトなら全く例外を使わないというのは極端なスタイルだと思うが。

**デフォルトの名無しさん** · 2019/03/15(金) 16:32:10.73

例外があると、それが理由で上下の階層が深いシステムになりがちだと思うよ。
節度があれば正直なんでもいいが、言語的にクソ設計を許さないのならその方がありがたい。

**デフォルトの名無しさん** · 2019/03/15(金) 16:54:37.47

c++じゃないところからc++のコード呼び出すなら例外外に出さないようにtry catchでラップするだけだし
逆で途中のコードが例外発生したために解放処理が飛ばされるってなら、raiiクラス化しろって話にならね？

通信経路でやり取りするなら相手が例外処理で実装されていようがされていなかろうがなんの関係もないし

**デフォルトの名無しさん** · 2019/03/15(金) 17:57:31.19

>>347
要は、メッセージングが至高ってことだな

**デフォルトの名無しさん** · 2019/03/15(金) 18:59:44.81

つまりJavaが至高。

**デフォルトの名無しさん** · 2019/03/15(金) 20:05:35.24

例外だしてどーすんの
ミッションクリティカルで直せるの？
意味ないじゃん

例外使いたきゃ専用言語使えばいい

**デフォルトの名無しさん** · 2019/03/15(金) 20:09:02.33

プログラミング言語の専門家に聞いて

**デフォルトの名無しさん** · 2019/03/15(金) 20:37:29.42

>>345
> 他の言語や過去の (例外をあまり想定していない) システムと接続することもあるし、
> そういう全体のエコシステムを考えると例外がかえって面倒ということはあると思う。
もうそういう極端な例でしか反論できないことはわかったよw

**デフォルトの名無しさん** · 2019/03/15(金) 20:59:33.43

江添勝てなかったか・・

**デフォルトの名無しさん** · 2019/03/15(金) 21:09:50.31

>>336
微妙に修正はされてる。
てかクソなc++本読むよりかよっぽど各機能の利点、問題点が簡潔に書けてると思うが。

**デフォルトの名無しさん** · 2019/03/15(金) 21:13:26.14

まだひっくり返る可能性はあると思うね

**デフォルトの名無しさん** · 2019/03/15(金) 21:50:38.17

>>335
pimplに限った話じゃないけど、前方宣言とそれによる定義の隠蔽が推奨されていない。

**デフォルトの名無しさん** · 2019/03/15(金) 22:07:25.54

Googleはな

**デフォルトの名無しさん** · 2019/03/15(金) 22:38:20.91

>>338
大規模なところでも例外禁止あるから
mozillaもそうでしょ
AAAなゲームスタジオでも多い
性能引き出したかったらそういう厳しい制約がいるんだよ

**はちみつ餃子** ◆8X2XSCHEME · 2019/03/15(金) 22:40:04.57

>>352
グーグルのガイドラインが極端なのは当たり前だ。
超巨大なエコシステムで成り立ってるわけだし。
例外を使わない派がしばしばグーグルのガイドラインを持ち出すんだけど、
そのガイドラインにすら、最初から設計してたら違ったかもしれないという
文言があるので、 C++ を使った設計理念一般としての強い根拠にならんのよな。

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

>>346
C++ はクソ設計でもどうにか形には出来るっていう方向性だと思う。
まともな設計ならそれが一番良いにきまってるけど、
それが期待できない場合が大半だという現実がある。

**KAC** · 2019/03/15(金) 22:48:06.41

例外禁止とかの環境って、
newの失敗とか毎回チェックするの？

**デフォルトの名無しさん** · 2019/03/15(金) 22:54:50.21

規約を守る守らんってことにしか目がいかんのな。
やっぱ馬鹿ばっかだわ。

**デフォルトの名無しさん** · 2019/03/15(金) 22:54:57.62

>>360
newの失敗のチェックって何するの？
null返ったかどうかのチェック？

**デフォルトの名無しさん** · 2019/03/15(金) 23:03:42.33

例外処理機構が無かったら、メモリ確保に失敗しても、
そこから過去のロールバックができない

自己流で、long jump するぐらいなら、例外処理の方がよい

**デフォルトの名無しさん** · 2019/03/15(金) 23:09:45.82

>>363
いや、失敗したら駄目だろ。失敗しないのが正しい。
プログラミング言語如きが考慮すべき問題ではない。

**デフォルトの名無しさん** · 2019/03/15(金) 23:18:26.60

>>363
そのロールバックってのはCとmallocじゃできないようなものなのかな。

**デフォルトの名無しさん** · 2019/03/15(金) 23:25:12.09

new失敗とかコンピュータが壊れてるからチェックしても意味ない

**デフォルトの名無しさん** · 2019/03/15(金) 23:27:22.88

当然特殊なケースは除くからな
一応言っておかないと組み込みガー君とか宇宙線でエラーガー君が飛んでくるからな

**デフォルトの名無しさん** · 2019/03/15(金) 23:37:27.23

>>359
＞私としては、一般的な C++ での設計の参考にするべきは標準ライブラリだと思う。
設計ではなく使い方の参考に、という意味では賛成だけど
テンプレートバリバリの設計はあまりにもコストがかかるというのを知っといて欲しい
ああいうのは湯水のごとく時間をかけられるからやれるんであって

**デフォルトの名無しさん** · 2019/03/15(金) 23:38:17.19

きみらはあれか、元記事とか全然読まずにコメントするクチか
リンク元には「例外は全く新規のプロジェクトならデメリットよりメリットが優先するので使って良い。
ただ既存のグーグルプロジェクトは元々例外を想定していないのでこれに例外のパターンを導入する
とリスクのほうが多いのでやめるべき。ただし Windows については例外がある(駄洒落ではない)」
と書いてあるんだがちゃんと読んだか。ちなみに駄洒落ではない、は俺が追加したのでなく元の文にある

**はちみつ餃子** ◆8X2XSCHEME · 2019/03/15(金) 23:45:56.39

>>368
そんな極端な意味では言ってない。
手間が合理的な範囲内で「参考」には出来るよって程度の話。

**デフォルトの名無しさん** · 2019/03/15(金) 23:48:42.07

エラーにはリカバリーすべきものとそうでないものがある
あとそのエラーが起こる頻度の違い

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

となると残りのリカバリーするものでかつたまにエラーがおこるようなのが例外にする価値があるエラー
あと例外発生時のunwindが重いからそれでも問題にならないもの
となるとあんまり使えるとこないんだよね
そういうわけで最近例外なしの言語がでてきてる流れなんだろう

**KAC** · 2019/03/15(金) 23:51:56.30

>>366
コンピュータが壊れない限りメモリ確保が失敗しない環境って凄いな。。。

**デフォルトの名無しさん** · 2019/03/15(金) 23:54:45.92

出、出～ｗｗｗ
一名いらっしゃいましたｗｗｗ

**デフォルトの名無しさん** · 2019/03/16(土) 00:07:16.61

例外ってcatchしなきゃ投げたその場で落ちてくれるのがこの上なく便利だろう
問題残したまま実行続けて別の関係ないところで落ちるのが最悪
runtimeで落ちて困るような用途でも、
ソースコードあるやつなら静的解析で例外発生箇所網羅出来そうなものだが
網羅できればリソースリークする危険な場所わかるし、対処も出来るのにね

逆にソースコード無いライブラリやダイナミックリンクする奴は、例外含めて外部仕様としてかっちり決まっているべきものじゃね

**デフォルトの名無しさん** · 2019/03/16(土) 00:11:00.29

>>374
> 例外ってcatchしなきゃ投げたその場で落ちてくれるのがこの上なく便利だろう

その場じゃなくstackが全部巻き戻ってからでしょ

**デフォルトの名無しさん** · 2019/03/16(土) 00:15:00.35

>逆にソースコード無いライブラリやダイナミックリンクする奴は、例外含めて外部仕様としてかっちり決まっているべきものじゃね
んなもんコンテナで隔離する以外使い道ねーわ。

**デフォルトの名無しさん** · 2019/03/16(土) 00:18:04.69

>>376
仕様ってのは例外外に出すか出さないか、
出すなら出し得る例外の種類のリスト
出さないならエラー毎にエラーコードやら返し方やら決めるって話

**デフォルトの名無しさん** · 2019/03/16(土) 00:23:45.45

そうなんだよね
例外の仕組みわかってないやつは平気で動的ライブラリの界面に
例外使ったりするんだよね
あと標準ライブラリ丸出しにするやつもしかり
それ誰も互換性保証してねーから

**デフォルトの名無しさん** · 2019/03/16(土) 00:24:47.11

>>376
核戦争を生き抜くには。

**デフォルトの名無しさん** · 2019/03/16(土) 00:24:57.90

まあ標準ライブラリの例外の使い方のおかしさも気になるが

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

いや、これ出る状況普通runtime_errorだよね

**デフォルトの名無しさん** · 2019/03/16(土) 00:29:24.58

>例外含めて外部仕様としてかっちり決まっているべきものじゃね

そこを言語の機構で保証できない、動的言語みたいななあなあ状態なのが残念なところだね。
それをきっちり保証しようとした検査例外はそれはそれで扱いづらいところがあるし。

**デフォルトの名無しさん** · 2019/03/16(土) 00:29:25.98

>>371
リカバリーするかしないか、頻度が高いか低いか、どちらもプログラム（特にライブラリ）を書いてる時点では
言い切れないから困るんですよねぇ。

**デフォルトの名無しさん** · 2019/03/16(土) 00:36:35.46

そこでプロパティ型なんですよ。

**デフォルトの名無しさん** · 2019/03/16(土) 06:11:19.71

>>372
無限にnewできる理想郷に住んでるんだろw
相手しなくていいよ

**デフォルトの名無しさん** · 2019/03/16(土) 06:46:32.47

復旧不可能な例外もあれば、些細な例外もあるよね。
戻り値チェックで十分でしょと思うようなところで例外を投げるJava/C#みたいな流儀だと、いちいちキャッチするのが面倒。

**デフォルトの名無しさん** · 2019/03/16(土) 06:52:39.99

Cでは戻り値で判定できたはずのエラー種別が例外クラスで細かく分類されてしまったことで、
エラー処理で書かなければならないコード量が増えて例外のキャッチ漏れまで起きる危険性が生み出された。

**デフォルトの名無しさん** · 2019/03/16(土) 07:31:06.00

その程度の知識で語ってる奴は戻り値方式でも処理漏れするだろw

**デフォルトの名無しさん** · 2019/03/16(土) 07:35:15.72

例外の嫌なところは
処理できない案件を低水準側に丸投げするところなんだよな…

ユニックスのプロセスの死亡順序もそうだが、
計算機業界は常識が逆転してゐる…

**デフォルトの名無しさん** · 2019/03/16(土) 07:38:02.24

というわけでおそらくアプリの設計ｼﾁｭの99%ぐらいは
　例外発生＝プログラムの死亡
、とみなして良いはず
ここまで割り切るならはじめて例外はお手軽で便利と言える

**デフォルトの名無しさん** · 2019/03/16(土) 12:28:02.50

例外をキャッチしたらプランBに移行するのが、真の戦闘のプロ。

**デフォルトの名無しさん** · 2019/03/16(土) 12:49:25.73

例外なんてグローバル変数みたいなもの。
だから低レイヤで使うのは仕方ない

**デフォルトの名無しさん** · 2019/03/16(土) 12:50:47.84

std::cin >> a;

は入力を延々と待っている。
これ別スレッドから止めさせる方法はありますか？

**デフォルトの名無しさん** · 2019/03/16(土) 13:10:50.41

stdin閉じるとどうなる？

**デフォルトの名無しさん** · 2019/03/16(土) 15:40:22.15

（組み込みはともかくアプリの場合は呼び出し元の方が高水準レイヤにあたるのではないかというツッコミが来ると思ったが
　来なかったので黙っていよう…

**デフォルトの名無しさん** · 2019/03/16(土) 17:27:11.59

>>390
プランBったって、プログラム起動時にあらかじめmallocしておいた何キロバイトかをfreeして
ダイアログを出して[OK]で終了、ぐらいなんじゃ…

**デフォルトの名無しさん** · 2019/03/16(土) 19:15:22.19

>>388
いや、プログラムでは、呼び出し側の方が高レベル、呼び出された側が低レベル
なので、呼び出された側が例外を投げた場合、高レベル側の関数で処理できる
ので適切。

**デフォルトの名無しさん** · 2019/03/16(土) 20:00:47.57

多くの例外の基底クラスになる exception にエラーコード整数値を出力する関数があればもう少しC寄りのエラー処理ができたと思うのだが。
既存のexceptionメンバ関数 const char *what() だけでは扱いが困難。

**デフォルトの名無しさん** · 2019/03/16(土) 20:14:28.85

std:::to_string();

**デフォルトの名無しさん** · 2019/03/16(土) 20:14:39.74

>>397
必要ならそういうクラスを定義するだけだろ

**デフォルトの名無しさん** · 2019/03/16(土) 20:15:00.26

sage

**デフォルトの名無しさん** · 2019/03/16(土) 20:39:18.42

ユーザーにエラー原因を示すだけならconst char*でも大して問題ないし、
catchした側でエラーコードによって何かするというのはたいていアンチパターン。

**デフォルトの名無しさん** · 2019/03/16(土) 22:15:57.75

文字をwchar_tで処理しているプログラムだと例外文字列作るのが面倒
まあ詳細な情報出さずに固定文字列にしてしまえばいいんだけど

**デフォルトの名無しさん** · 2019/03/17(日) 00:42:25.28

templateの使い道がいまいちわからん
STLやboostみたいなものは非常に有益だが

同僚がドヤ顔でコンテナを作ったって自慢してたが、
stlのコンテナを使わずにそいつのコンテナを使う理由が無い

**はちみつ餃子** ◆8X2XSCHEME · 2019/03/17(日) 00:46:12.21

>>403
困ってないなら使わなくてもいいと思うよ。
困る場面がある人のための機能。

**デフォルトの名無しさん** · 2019/03/17(日) 00:48:31.10

同じコードをコピペしなくて済むから、作業量も減るし、保守も楽になる。

**デフォルトの名無しさん** · 2019/03/17(日) 00:56:16.88

>>403
せやな
ただそれは作るものの需要の有無の問題だ

**はちみつ餃子** ◆8X2XSCHEME · 2019/03/17(日) 00:58:29.44

重複があることを事前に発見するのは難しい場合もあるから、
同じことを何度も書いている気がするなと思ったら
どうにかしてまとめることを検討するという程度でもいいかもね。

同じことをしないようにする、いわゆる DRY 原則というものはあるけど、
一方で、それを意識するあまりしなくてよい抽象化層を設けるのも馬鹿らしいということで、
必要になってからやるという YAGNI という考え方もある。

こういうのは程度問題なので、なんでもほどほどにね。

**デフォルトの名無しさん** · 2019/03/17(日) 01:15:02.15

テンプレート（のパラメータにおける型の自動推論）と
関数のオーバーロードの合わせ技によるコードのまとめ力は異常

**デフォルトの名無しさん** · 2019/03/17(日) 01:37:37.76

例えばストレージからintを読み込む関数、doubleを読み込む関数、unsigned charを読み込む関数を
同じ関数名と同じ引数の並び（例えばbool read(FILE* fp, <目的とする型>& x とか）ででオーバーロードしておけば、
template<class T1, class T2, class T3>
bool read_x3(FILE* fp, T1& x1, T2& x2, T3& x3) {
　if (!read(fp, x1)) { return false; }
　if (!read(fp, x2)) { return false; }
　if (!read(fp, x3)) { return false; }
　return true;
}
でもって、オーバーロードを実装した任意の型3個の組み合わせについて読込関数が実体化される
（実装されていない型に行き当たったらエラーになるからﾜｶﾙ
これはn個の関数と1個のテンプレートを書いただけで、n^3パターンもののユースケースに網羅的に対応できたことになるからｽｹﾞｰ強力

※ 個人の感想です

**デフォルトの名無しさん** · 2019/03/17(日) 01:43:06.21

>>409
そこはfpも抽象化でしょ。
intハンドル、FILE*、iostream、HANDLE などなど派生関係のないものをtemplate化できる。

**デフォルトの名無しさん** · 2019/03/17(日) 01:44:01.66

なおこのﾃｸをつきつめれば、テンプレートの特殊化というのは普通の意味では要らなくなるｷﾓｽ、
むしろ特定の型の組み合わせについて自動展開を禁止したいときに使う
（例えば可変長データのread関数を、データの先頭にデータの個数を書く約束で作ったとして、
　個数を読み込む関数を整数のread(fp, x)に限定したい場合、個数の型をdoubleにした特殊化テンプレートを書いてわざとエラーにするとか、

**デフォルトの名無しさん** · 2019/03/17(日) 01:47:31.21

>>410
FILE* fpは十分汎用的でしかも最大限高速なので他への代替の必要性はほとんど考えられないし、
サンプルコードでむやみに凝っても仕方が無い

※ 個人の感想です

**デフォルトの名無しさん** · 2019/03/17(日) 01:58:32.33

テンプレートはヘッダに全部書かなきゃいかんのなんとかならんか？

**デフォルトの名無しさん** · 2019/03/17(日) 02:06:35.73

原理上どうにもならない

**デフォルトの名無しさん** · 2019/03/17(日) 02:10:16.54

テンプレートの分割コンパイルは一度実装されたが1年がかりの複雑な仕事になったし
あまりに複雑すぎて普及に至っていないというようなことがプログラミング言語C++で読んだ記憶、

しかし、importキーワードがC++の予約語であるうちはまだ希望がある

**デフォルトの名無しさん** · 2019/03/17(日) 02:10:32.44

FILE* fp は標準のfgetc()の実行速度が遅くて残念。バッファリングしている甲斐がない。

**デフォルトの名無しさん** · 2019/03/17(日) 02:26:35.34

使いたい型決まっているなら別にできるだろ？
ヘッダで宣言だけ書いて、ソースで定義と明示的インスタンス化すればいいだけ

**デフォルトの名無しさん** · 2019/03/17(日) 02:34:45.67

3大C++無限ループ話題

テンプレート実装の分割記述
getsetの実装

あと一つは？

**デフォルトの名無しさん** · 2019/03/17(日) 03:18:11.89

多重ループの抜け方

**デフォルトの名無しさん** · 2019/03/17(日) 03:19:37.14

STLにツリーがない理由を教えてください。

**デフォルトの名無しさん** · 2019/03/17(日) 04:14:30.81

あるクラスが非トリビアルなコピーコンストラクタをもっていることを検出したい
そのクラスのメンバの型が非トリビアルなコピーコンストラクタを持っていたとしても。

**デフォルトの名無しさん** · 2019/03/17(日) 06:02:45.37

>>418
メモリが云々

**デフォルトの名無しさん** · 2019/03/17(日) 06:48:43.74

>>413
テンプレートを抜き出してヘッダーファイルを生成するプリプリプロセッサを作ればいい

**デフォルトの名無しさん** · 2019/03/17(日) 08:23:20.60

>>421
トリビアルコピー出来ないことを検出したいならis_trivially_copyableで充分だけどそれ以上のことがしたいの？

**デフォルトの名無しさん** · 2019/03/17(日) 08:28:29.93

>>409
糞抽象化の見本みたいなコードだなw。
そのうち使われなくなる種類のコードだ。

**デフォルトの名無しさん** · 2019/03/17(日) 08:33:05.90

名人様一名いらっしゃいました

**デフォルトの名無しさん** · 2019/03/17(日) 11:20:51.42

>>411
＞　個数の型をdoubleにした特殊化テンプレートを書いてわざとエラーにするとか、
そういうときはdelete指定が使えるんじゃね？
というかis_floating_pointとかで弾いた方がいいとも思うけど

**デフォルトの名無しさん** · 2019/03/17(日) 12:03:09.87

>>409
x3とかつけない方が良くね？
てかvariable template使うところだね

**デフォルトの名無しさん** · 2019/03/17(日) 13:22:57.65

variadicだた

**デフォルトの名無しさん** · 2019/03/17(日) 13:42:47.24

バリスティック・テンプルね。

**デフォルトの名無しさん** · 2019/03/17(日) 15:09:36.00

>>425
サンプルにまでマウントするとかw

**デフォルトの名無しさん** · 2019/03/17(日) 15:29:33.79

マウントの定義を教えてください。

**デフォルトの名無しさん** · 2019/03/17(日) 16:01:22.88

明確な定義があるわけじゃないけど、主に「勘違いした高卒が高等な他人を見下してること、もしくはその様」を指す語としてつかわれてんじゃないの

**デフォルトの名無しさん** · 2019/03/17(日) 21:10:58.21

>>432
意識高い系

**KAC** · 2019/03/17(日) 21:23:45.76

>>432
猿などが優位だと主張するために
相手に馬乗りになること

こういう場では、
相手に反論した（つもり）なら満足し、
反論を受けると過剰反応を示す奴をさすことが多い。

**デフォルトの名無しさん** · 2019/03/17(日) 21:42:19.60

>>435
＞相手に反論した（つもり）なら満足し、
＞反論を受けると過剰反応を示す奴をさすことが多い。
その説明だと某クソコテしか思い当たらないんだが・・・w

◆QZaw55cn4c · 2019/03/17(日) 21:57:43.35

>>436
誰？

**デフォルトの名無しさん** · 2019/03/17(日) 22:22:05.53

オープンソース化されたWindowsの電卓を見たが、クッソ綺麗でモダンなコードだな

**デフォルトの名無しさん** · 2019/03/17(日) 22:25:37.54

多分7に入ってた電卓とは別物だな

**デフォルトの名無しさん** · 2019/03/17(日) 23:22:31.89

>>438
あの手のコードって意味ないよな
無意味に11や14で追加された機能をなんかを使いたがるやついるわー
そういったやつに限って仕事が遅い

ウンチクはいいから、さっさと終わらせろよ

**デフォルトの名無しさん** · 2019/03/18(月) 00:13:57.67

Windowsカーネルのオープンソース化待ってます