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/10(日) 23:21:10.96

そのベースの型は実装依存
型を取りだして使えってことなんだろうか

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

なんでenum classなんだ？
typedefと何が違うの？

**デフォルトの名無しさん** · 2019/03/10(日) 23:31:19.81

暗黙の型変換ができない

**デフォルトの名無しさん** · 2019/03/10(日) 23:54:49.98

こういうの行き過ぎた型安全に思えるけどね

**デフォルトの名無しさん** · 2019/03/10(日) 23:57:35.21

でも過去にそれで何かあったんでしょ
使うかどうかは任意だしある分には困らない

**デフォルトの名無しさん** · 2019/03/10(日) 23:57:38.91

なるほど

**デフォルトの名無しさん** · 2019/03/11(月) 00:01:39.15

is_enum_vがtrueになるとか違和感しかない

**デフォルトの名無しさん** · 2019/03/11(月) 05:30:01.20

>>265
なんで
uchar8_t
uchar16_t
uchar32_t
にしないんだろな

**デフォルトの名無しさん** · 2019/03/11(月) 05:58:05.15

既存のライブラリと衝突しまくるだろそれ

**デフォルトの名無しさん** · 2019/03/11(月) 11:02:11.57

>>273
ひとりで全部作ってんのか？
誰か使い始めたらそれに巻き込まれるんだよ

**デフォルトの名無しさん** · 2019/03/11(月) 13:49:05.84

WPFってどうなの

**デフォルトの名無しさん** · 2019/03/11(月) 19:42:26.86

塵

**デフォルトの名無しさん** · 2019/03/11(月) 22:05:24.43

getoptの標準化マダーチンチン(AA略

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

void foo(std::function<void()> &&f){}

int main(){
auto lamda = [](){};
foo(lamda);
}
なぜコンパイルできるの？

**デフォルトの名無しさん** · 2019/03/12(火) 07:23:08.39

>>281
オプションの渡し方がそもそも揺れてる

**デフォルトの名無しさん** · 2019/03/12(火) 07:25:00.12

>>282
int main()
{
return main();
}
なぜコンパイルできるの？

**デフォルトの名無しさん** · 2019/03/12(火) 11:46:00.90

int main(std::function<void()> &&f){
return main([](){});
}

**デフォルトの名無しさん** · 2019/03/12(火) 20:22:26.93

すいません、低レベルのかたたちばかりでした。
聞くところ間違えました

**デフォルトの名無しさん** · 2019/03/12(火) 20:30:56.16

なぜc++ main return省略でググらないのか

**デフォルトの名無しさん** · 2019/03/12(火) 20:43:58.42

getoptを標準化してしまうとハイフンで始まる変態ファイル名が鬼門になってしまうかな。

**デフォルトの名無しさん** · 2019/03/12(火) 20:46:35.39

is_iterator、is_containerメタ関数はどうやったら作れるんでしょうね？

**デフォルトの名無しさん** · 2019/03/12(火) 20:54:07.45

SFINAEでググれ、でいいんだろうか

**デフォルトの名無しさん** · 2019/03/12(火) 20:55:53.60

スフィ姉は知っているんですが。
そのあとが。

**デフォルトの名無しさん** · 2019/03/12(火) 21:00:20.04

iterator_traitsに通してメンバ型が得られるか確認する？
*とか++とかの操作について確認する？
containerはbeginとendでイテレータ取れるか確認する？

**デフォルトの名無しさん** · 2019/03/12(火) 21:34:26.86

template <typename T>
using is_iterator = std::is_class<typename std::iterator_traits<T>::iterator_category>;
これは使えますかね？

**デフォルトの名無しさん** · 2019/03/12(火) 21:58:48.29

ぐぐればstack overflowがひっかかる

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

使えますかねって・・自分で試せるだろ

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

マウントしててワロス

**デフォルトの名無しさん** · 2019/03/12(火) 22:34:48.05

マウントは取りたいけど教えるのはめんどくさい

**デフォルトの名無しさん** · 2019/03/12(火) 22:48:31.61

結局はそれで何がしたいかによるんじゃね
標準のコンテナやそのイテレータで型分岐したいなら十分だけど、カスタム実装されたユーザー定義のイテレータがそのように実装されているかは分からんし
まあiterator_traitsの特殊化も追加で書くようにすれば使えるか

**デフォルトの名無しさん** · 2019/03/12(火) 23:06:42.78

C++20からは一応イテレータはコンセプトがあるなあ
コンテナは知らん

**デフォルトの名無しさん** · 2019/03/12(火) 23:12:51.59

>>293
はダメな気がするな
template<typename T,typename=void>
struct is_iterator:std::false_type{};

template<typename T>
struct is_iterator<T,std::enable_if_v<std::is_class_v<typename std::iterator_traits<T>::iterator_category>>>:std::true_type{};

**デフォルトの名無しさん** · 2019/03/12(火) 23:14:38.07

>>296,297
アホか、何がマウントだボケ
自分で試しもせずに2chに丸投げとか普通にダメだろ

>>298
iterator_traitsに与える型の要件(だけでいいかどうかはさておき)を満たすなら特殊化なんかいらんでしょ
リファレンス見る限り、iterator_traitsの特殊化はポインタのためだけにあると思う

**デフォルトの名無しさん** · 2019/03/12(火) 23:27:20.69

>>300
どの本もそういう書き方になってるんだけど、その理由がわからない。
>>293は呼び出し方によっていろいろ問題が起きるんだけど、その理由がわからなさすぎる。
その辺がスッキリわかる本はないですかね。

**デフォルトの名無しさん** · 2019/03/12(火) 23:39:14.10

本は知らん
SFINAEが使えるのは宣言部分
そこで置換失敗すると宣言そのものが無かったことになる

**デフォルトの名無しさん** · 2019/03/13(水) 12:04:15.67

>>297
マウントが取りたいだけで教える知識がないだけやねんｗ

**デフォルトの名無しさん** · 2019/03/13(水) 12:37:00.35

そう
分からない質問には自分で試せ
これがC++使ってる奴の特徴

**デフォルトの名無しさん** · 2019/03/13(水) 12:47:27.60

>>304,>>305
そう思うなら自分が教えてやれば？

**デフォルトの名無しさん** · 2019/03/13(水) 20:50:37.56

規約はあるけど「実装が規約」をやっちゃってる部分が多くて、
しかもコンパイラのバージョン依存がひどいってのがc++だからな。
規約は語れても実際にどう動作するか語れない輩も多いだろうね。

**デフォルトの名無しさん** · 2019/03/13(水) 21:07:13.50

そういう構図じゃないと思うよ

**デフォルトの名無しさん** · 2019/03/13(水) 21:25:53.81

どなたか iostreamの存在価値について熱く語ってくれないか。

**デフォルトの名無しさん** · 2019/03/13(水) 21:34:23.99

いやだ

**はちみつ餃子** ◆8X2XSCHEME · 2019/03/13(水) 21:38:23.77

>>309
https://www.google.com/search?q=%22iostream%E3%81%AE%E4%BE%A1%E5%80%A4%22

**デフォルトの名無しさん** · 2019/03/13(水) 21:55:23.80

VS2019って4月2日に出るのかな？

**デフォルトの名無しさん** · 2019/03/13(水) 22:19:08.88

米国時間4/2にローンチイベント行ってるから日本だと3日かな

**デフォルトの名無しさん** · 2019/03/13(水) 22:44:27.53

>>306
だから分からないのにマウント取るのやめたら？

**290=301** · 2019/03/13(水) 23:05:00.60

>>314
バカだろお前

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

> だから分からないのにマウント取るのやめたら？
お前のことだよ

**デフォルトの名無しさん** · 2019/03/14(木) 18:41:51.50

>>313
待ちどおしいね。

**デフォルトの名無しさん** · 2019/03/14(木) 20:57:09.31

このスレの住人は、新しいVisual Studioでどんなことに期待してるの？

**デフォルトの名無しさん** · 2019/03/14(木) 20:58:50.91

>>317
マウントされないこと

**デフォルトの名無しさん** · 2019/03/14(木) 21:00:03.79

仕様通りに動いてくれりゃそれでいいわ。

**デフォルトの名無しさん** · 2019/03/14(木) 21:20:35.00

C++20の早期対応

**デフォルトの名無しさん** · 2019/03/14(木) 21:25:28.09

clang対応

**デフォルトの名無しさん** · 2019/03/14(木) 21:29:12.31

C#での使い勝手向上

**デフォルトの名無しさん** · 2019/03/14(木) 21:36:15.68

フロントエンドをVSCodeにしてくれ

**デフォルトの名無しさん** · 2019/03/14(木) 21:45:44.62

メモリ喰わずに軽くなって…

**デフォルトの名無しさん** · 2019/03/14(木) 22:54:08.60

何個まで願い事聞いてくれるんだろ。

**デフォルトの名無しさん** · 2019/03/14(木) 23:13:56.40

>>317
Expressを出してくれ

◆QZaw55cn4c · 2019/03/14(木) 23:19:01.48

>>317
MFC…

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

Windows formsのC++へ移植してmfcを完全に抹消してくれ

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

>>317
オープンソース化

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

本当によくかけとるわ。
この人たちで標準委員やったほうがいいんじゃないかと思う。
https://ttsuki.github.io/styleguide/cppguide.ja.html

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

ゴミ

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

けっこう癖が強いよね。例外やpimpl否定したり。

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

危険思想だなｗ
ヤバすぎてヘドが出るｗ

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

まあでかいプロジェクトはこんなもんだろう。
例外は実際よくないと思うわ。

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

pimpl否定ってあったっけ？
うちのプロジェクトも原則例外禁止
むかしは一律禁止だったけど

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

>>330
古くさいって言われてなかった？

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

googleのスタイルガイドは和訳が古くて英語版しか読まなくなって何年にもなるが追いついてるのか？

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

例外無しとか小規模の組み込み以外で意味あるのかね？

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

例外使った時点で疎結合もへったくれもなくなると思うわ。
能力的に幅のあるプロジェクトで使うには難しいよ。

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

>>339
> 能力的に幅のあるプロジェクトで使うには難しいよ。
これには同意するけど

> 例外使った時点で疎結合もへったくれもなくなると思うわ。
意味不明
例外以外の方法使っても似たようなことをする羽目になるだけ
なら意図が明確な例外のほうがマシ

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

戻り値なら呼び出し元と呼び出し先の間の結合だけだが、例外はよりコールスタックの根本の方へ結合が及ぶことがある
フレームワークのように、例外を使ってあえて中間をすっ飛ばしてコールスタックの上と下を結合させるケースもあるけどね

**デフォルトの名無しさん** · 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++ での設計の参考にするべきは標準ライブラリだと思う。
設計ではなく使い方の参考に、という意味では賛成だけど
テンプレートバリバリの設計はあまりにもコストがかかるというのを知っといて欲しい
ああいうのは湯水のごとく時間をかけられるからやれるんであって