C++相談室 part144

**デフォルトの名無しさん** · 2019/07/22(月) 13:18:35.52

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

前スレ
C++相談室 part143
https://mevius.5ch.net/test/read.cgi/tech/1560574313/

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

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

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

----- テンプレここまで -----

**デフォルトの名無しさん** · 2019/08/20(火) 14:29:19.64

よくあるような、
if ( (c >= 'A' && code <='Z') || (c >= 'a' && code <='z') ||
　　c == '_' ) {
　・・・
}
の部分を、条件jmp文が少しでも少なくなるようにと思って、
予め作成しておいたテーブル(配列)を使って、
if ( eiji_or_underscore[c] != 0 ) {
　・・・
}
として実測してみたところ、何度計測しても後者の方が遅くなった。
アセンブリコードを見てみても、前者だと5つの条件jmp命令、後者だと1つの条件jmp命令と、
後者の方が命令数が少なくっていた。しかし、前者だと、レジスタとcmp命令を使っていたが、
後者だとグローバル変数の配列を読み出しに行っていた。

最近のCPUは非常に複雑で高度な「分岐予測」をしていて、配列は読み出してみないと
値が分からないので、「予測」ができず、分岐予測の「予測間違い」がおきるが、
レジスタをcmpで比較する場合には予測が出来るためだろうか。

しかし、昔より最適化する際にどっちが高速になるかの予想が難しくなってしまってる。

**デフォルトの名無しさん** · 2019/08/20(火) 14:39:39.94

>>567
誤：if ( (c >= 'A' && code <='Z') || (c >= 'a' && code <='z') ||
正：if ( (c >= 'A' && c <='Z') || (c >= 'a' && c <='z') ||

**デフォルトの名無しさん** · 2019/08/20(火) 14:40:33.96

分岐予測はデータの内容関係ないやろ

**デフォルトの名無しさん** · 2019/08/20(火) 14:48:01.70

最近の環境では「実測」の信頼性確保も、また難しいです。
なぜかある時には何度測定しても遅いのに、あらためて別の時に
測ると速く出る事があったりします。

**デフォルトの名無しさん** · 2019/08/20(火) 14:48:40.12

単にテーブル参照はメモリーから読み出すから遅いだけだろ

**デフォルトの名無しさん** · 2019/08/20(火) 14:49:27.63

俺が書いた通り、単にメモリへのアクセスが遅いんだよ

**デフォルトの名無しさん** · 2019/08/20(火) 15:08:33.40

理論上は、メモリがキャッシュに乗っている限り、メモリの読み書きとレジスタ
への読み書きの速度は同一です。

ただし、メモリとメモリは add, sub, mov 命令で2つのオペランドに同時指定は
出来ないのに対し、レジスタは出来るので、確率的にレジスタの方が必要な
命令数が少なくて済むので高速になる場合があります。
あとキャッシュに乗って無い場合はメモリは遅くなります。

**デフォルトの名無しさん** · 2019/08/20(火) 15:22:22.32

>>571
アホか>>567読み直せ

**デフォルトの名無しさん** · 2019/08/20(火) 15:23:45.52

あ、すまん俺の方が間違えてた・・
まさかとは思うけど最適化してないとか無いよね

**デフォルトの名無しさん** · 2019/08/20(火) 15:29:52.16

>>575
最適化はどちらも同じオプションでしてますし、出力されたアセンブリ・コード
も見て、テーブルを使った方が命令数の少ないコードになっていることも
確認してます。条件jmp命令も少なくなっています。

**デフォルトの名無しさん** · 2019/08/20(火) 15:30:02.90

あと前者のコードは与えたcの値がA-Zだと分岐の回数2回で済むからじゃないかね

**デフォルトの名無しさん** · 2019/08/20(火) 15:36:01.76

>>577
実はその影響もあると思っているのですが、それだけだと前者の場合には、
命令数から言えば1～2クロックほど速くなる場合がある程度です。
しかし、実測してみると、後者のやり方の方がもっと遅くなっている
ようなんです。

面倒ですが、マクロスイッチでコードを切り替えられるようにして
短時間の内に二つを切り替えて速度比較してみようかと思っているところです。

**デフォルトの名無しさん** · 2019/08/20(火) 15:51:20.21

最近のCPUは温度によってクロック数が変動する可能性もあるそうですね。

**デフォルトの名無しさん** · 2019/08/20(火) 16:13:18.12

テーブルがキャッシュに乗ってなかったり、
>>561と同じでテーブルがグローバル変数だと書き換えを懸念して最適化ぎ抑制されてんじゃないかな

**デフォルトの名無しさん** · 2019/08/20(火) 16:16:16.40

レンジエラーになりそうで怖い。っていう横やり。

**デフォルトの名無しさん** · 2019/08/20(火) 16:23:55.23

マクロスイッチ切り替え方式にして、ほぼ同時に両方を測定してみたら、
テーブル方式の方が速くなっていました。

**デフォルトの名無しさん** · 2019/08/20(火) 16:32:21.29

キャッシュ汚染とかの話になったの？

**デフォルトの名無しさん** · 2019/08/20(火) 17:25:38.94

>>580
アセンブリコードを見る限り、特に問題なく、人間が単純に書いた場合
と似たようなコードになっています。

ただし、一点、テーブルの c 番目の要素を参照する際、バイト整数の c
をゼロ拡張して32BIT 整数にする必要があるのですが、自分の使ってるVC++
だと、movzx 命令を使わずに、xor eax,eax; mov al,cl のように2命令
を使ってしまっている点が、人間が最適化するより遅いコードになってしまって
います。

**554** · 2019/08/20(火) 18:34:23.13

コメントありがとうございます。

>>555
エンディアンを気にしないといけないのは後々分かりづらくなりそうですね。。

memcmpというのがあったんですね。
連続バイト比較ができてシンプルで良さそうです。
これを使ってみます。

**デフォルトの名無しさん** · 2019/08/20(火) 19:55:32.24

volatile命令の他にキャッシュ命令とか無いのかよ
ルックアップテーブルをキャッシュに載せときゃ爆速じゃん
もっと言えばテーブルを石に焼いた時一番早い

**デフォルトの名無しさん** · 2019/08/20(火) 22:55:27.89

>>569
>分岐予測はデータの内容関係ないやろ
分　岐　予　測　は　デ　ー　タ　の　内　容　（統計的偏り）　に　関　係　あ　る

>>567
最近のCPUは黒魔術で製造されているからミクロな最適化を下手に人が手を加えるより
単純なアルゴリズムにした方が速いことが多くなた
印象

**デフォルトの名無しさん** · 2019/08/20(火) 23:22:44.05

>>587
お前はアレか
>>567の言う「配列は読み出してみないと値がわからないので、予測が出来ず」
が正しいと？

**デフォルトの名無しさん** · 2019/08/21(水) 01:15:10.83

多分メモリが読めてない状態でも分岐予測して投機的実行はするんじゃないかな
近代的なCPUは

**デフォルトの名無しさん** · 2019/08/21(水) 05:42:53.52

>>567の前半部のコード
>if ( (c >= 'A' && code <='Z') || (c >= 'a' && code <='z') ||
>　　c == '_' ) {
>　・・・
>}
はCPUレベルの分岐予測＋投機的実行では入力データによっては速度向上し難いケースがある
　AaZz_AaZz_AaZz_....
という入力を考えたらﾜｶﾙ（cといして1文字入力される度に||か&&を打ち切る分岐箇所がちがーう
分岐予測キャッシュというのは分岐命令1個につき1状態か2状態記憶がせいぜい（しかもLRU式に記憶が消える
のでこのような場合は投機的実行結果が捨てられ続けかねない

>>598
ハイ論破

>>589
分岐予測と投機的実行が効力を発揮するのは多重ループで内側の分岐条件が大部分の時間変わらないというケース

**デフォルトの名無しさん** · 2019/08/21(水) 05:59:08.65

ちゅか&&や||の条件式に関数呼び出しが含まれない単純なケースにおいては、
OoOと分岐予測を備えた今日日のCPUでは途中で打ち切るより全部評価してしまった砲が速い可能性がおおきい
このとき問題になるのは副作用のある式が問題であり、
副作用がある++や--があると、やっぱ言語規格どおり||や&&は条件成立で打ち切らないとソースコードに書かれた気体動作と
オブジェクトコードの動作が別物になってしまうので諸悪の根源
C言語を引きずった仕様のままでは時代について逝けてない

Rustで++や--を式の中で使えないのは故無きことでは無いんじゃ…

**デフォルトの名無しさん** · 2019/08/21(水) 06:00:45.09

ｽﾏﾝGoと混同した
Rustに++や--は無い

**デフォルトの名無しさん** · 2019/08/21(水) 06:13:21.67

もうRustはいいから

**デフォルトの名無しさん** · 2019/08/21(水) 07:20:20.39

>>590
> （しかもLRU式に記憶が消える
知ったか乙
せめて
https://ja.m.wikipedia.org/wiki/分岐予測
くらいは読んでこい

> のでこのような場合は投機的実行結果が捨てられ続けかねない
そりゃ頑張って作れば最悪の状況は作れるよw
だから何？って話だが

**デフォルトの名無しさん** · 2019/08/21(水) 10:08:42.06

>>590
そういう安価ミスはちゃんと訂正しろよ
あと反論になってない
語弊はあったろうけど配列だから分岐予測が効かないなんて話はないだろうと言いたかっただけだ

**デフォルトの名無しさん** · 2019/08/21(水) 20:40:17.99

>>586
1バイトの即値データとの比較の方が速いに決まってんだろ。
命令デコードする段階で比較対象のデータとってこれるんだから

**デフォルトの名無しさん** · 2019/08/21(水) 22:54:56.30

>>594
リンク先のどこにLRUでは無いと書いてあるんじゃ…
分岐予測キャッシュがあふれたときはLRUが基本
これは2次キャッシュを儲けても関係ない（それぞれの中で溢れたらLRU
むしろハードウェア実装の制限でLRUより性能の落ちるしくみを使うこともある
が（nウェイセットアソシアティブの「アソシアティブ」部分は一部アドレス線の固定解釈による簡素化

>>595
分岐予測が性能を発揮しない例が有る以上ハイ論破の訂正の必要は認められぬ

**デフォルトの名無しさん** · 2019/08/21(水) 23:02:56.86

もし分岐予測制度を上げるためのキャッシュエントリのn状態化とキャッシュが溢れた場合の話を
混同しているんだとしたらきわめておめでたい話だといえる

あるアドレスの分岐命令に対応するキャッシュエントリがどの状態に居たとしても、
そんあことはお構いなしに溢れたときはどれかのエントリが消される.。
このとき他の制約が無ければ理想解はLRUという話

**デフォルトの名無しさん** · 2019/08/21(水) 23:16:22.08

ていうか
>1状態か2状態記憶がせいぜい（しかもLRU式に記憶が消える (>>590
とまで書いたのだからキャッシュエントリのn状態化は機知の前提で話していることぐらいは読み取って
ﾎｽｲ
（雑駁なリンク先を示すよりはむしろ「1状態って何だよ2状態だろパーカｗｗｗｗｗｗｗ」ぐらいの反応であれば>>594は知性を疑われずに済んだ

**デフォルトの名無しさん** · 2019/08/21(水) 23:18:51.67

ただのこじつけじゃねーか
てかそんだけ御託並べて質問者へのアドバイスはゼロかw

(というかこいつの論調どっかで見たな・・・)

**デフォルトの名無しさん** · 2019/08/22(木) 00:05:50.83

>>597-599
分岐予測はキャッシュじゃねーぞw
反論するなら分岐予測にLRUアルゴリズムを使ってる奴はCPU挙げてみな

**デフォルトの名無しさん** · 2019/08/22(木) 10:59:48.20

いや、まてまて、そもそも今の話は、分岐予測の精度は関係無いのでは？

>「配列は読み出してみないと値がわからないので、予測が出来ず」

がおかしいって話でしょ
精度はともかく、分岐予測はするでしょ
というか、逆に、値が分からないから分岐予測するようなもので

分岐予測の精度に関しても、if文のかっこの中の計算が終わってない状態で
適当にジャンプするのは同じでしょ、配列が読めてようが読めてなかろうが

**デフォルトの名無しさん** · 2019/08/22(木) 11:58:47.76

そりゃー予測なんかせず配列まるまる全部をキャッシュに乗せるから早いんだろ
つまり予測しないルックアップテーブルの時が一番早い
そのテーブルがCPUに焼きこんであればもっと早い

**デフォルトの名無しさん** · 2019/08/22(木) 13:09:16.96

いやだから、ルックアップテーブルの結果を受けて分岐する話なんだから・・
おかしなこと言うな

**デフォルトの名無しさん** · 2019/08/22(木) 14:18:30.45

イキってるパソコンの大先生の子供部屋おじさんがいますね…

**デフォルトの名無しさん** · 2019/08/22(木) 15:51:21.48

多くのCコンパイラがサポートしてるquadmath (__int128とか__float128とかその関数)がかなり便利なのですが、なぜこれはC++の標準の機能にならなかったのですか？

**デフォルトの名無しさん** · 2019/08/22(木) 18:02:39.65

殆んどのハードでの実装がソフトで遅いし、需要も少ない
使いたきゃboostにあるし

標準化されるとしたら、x86とかでハード実装された後に標準型として対応するんじゃね？
てかlong doubleがワケわからんことになっているのをどうにかしろと

**デフォルトの名無しさん** · 2019/08/22(木) 18:28:45.94

'A' から 'Z と 'a'から'z'　は連続した文字コードである
ここにcpuの速度の秘密がある　はず

**デフォルトの名無しさん** · 2019/08/22(木) 19:44:40.23

>>608
> 'A' から 'Z と 'a'から'z'　は連続した文字コードである
はあ？

**デフォルトの名無しさん** · 2019/08/22(木) 20:52:16.00

>>606
大型計算機にすら倍々精度をハードウェアで扱ってないもんな
命令体系は用意されてるけど
ソフトで十分ってこった

**デフォルトの名無しさん** · 2019/08/22(木) 20:56:48.17

>>606
ところで、そんな精度を何に使ってるの？

**デフォルトの名無しさん** · 2019/08/22(木) 20:59:38.41

float128よりdecimal64の方が需要あるんじゃね

**デフォルトの名無しさん** · 2019/08/22(木) 21:59:41.74

>>612
それ金融でほしいやつだな。
国家予算研究できるな！

**デフォルトの名無しさん** · 2019/08/22(木) 22:01:20.66

そこでCOBOLですよ

**デフォルトの名無しさん** · 2019/08/22(木) 22:10:35.40

KaMiの言語・コボル　かー。

読めんわ！！！

**蟻人間** ◆T6xkBnTXz7B0 · 2019/08/22(木) 22:26:31.30

https://github.com/LiraNuna/soft-ieee754
こういうのもあるよ。
自分のデータ型を作ろうとすればできないこともない。

**デフォルトの名無しさん** · 2019/08/22(木) 22:29:56.92

>>616
金融計算をIEEE754(？)でやってはいけないのだ。
2進化10進数でやらないと誤差が出る。

**デフォルトの名無しさん** · 2019/08/22(木) 22:53:17.49

二進化十進数でも誤差でるから
当たり前だけど
有理数でやるんだよ

**デフォルトの名無しさん** · 2019/08/22(木) 22:59:39.88

そういう話じゃない。
金融計算では10進数のどの桁でどういう丸めを行うか決まっているから、
その通りの結果になることが「誤差がない」状態なんだよ。

**デフォルトの名無しさん** · 2019/08/22(木) 23:13:26.11

普通そういうのは多倍長整数じゃないのか

**デフォルトの名無しさん** · 2019/08/23(金) 00:16:10.19

>>611
畳み込み和の計算はフーリエ変換して求めておいて最後に逆変換することで高速化できます (畳み込み定理) が、しばしば誤差の増大がネックになります
こういう問題で出てくる整数はとても大きいということもあります
だから巨大な数を普通に扱いたいのです

数論変換 (整数環上でのDFT) をすれば良いのですが、もっと単純化できないかという試行錯誤です

**デフォルトの名無しさん** · 2019/08/23(金) 00:39:49.78

蒸し返すようですいませんがGNU Makeに取って代わるデファクトスタンダードなビルドシステムってCMakeじゃないんですかね

**デフォルトの名無しさん** · 2019/08/23(金) 02:34:27.19

>>608
規格で保証されてるのは'0'から'9'が連続してることだけな

**デフォルトの名無しさん** · 2019/08/23(金) 21:07:50.69

>>622
取って代わるというかmakefileをつくるメタビルドツールって方が認識として正しい。
実際cmakeでwindowsでもlinuxでもビルドできるように設定するのはマジ辛いぞ。

◆QZaw55cn4c · 2019/08/23(金) 21:29:52.90

>>624
そういうのは　windows 用と linux 用にわけるんじゃないでしょうか？

**デフォルトの名無しさん** · 2019/08/23(金) 21:30:32.32

CMakeもAutoconfなんかと比べたら簡単になったんだろうけど、自分で書くならgypだな。

**デフォルトの名無しさん** · 2019/08/23(金) 21:42:53.01

>>625
cmakeを何だと思ってる
使ったことないのかよ

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

馬鹿朝鮮人が使ってるわけないだろ

**デフォルトの名無しさん** · 2019/08/23(金) 23:21:07.68

automake/autoconfに慣れたからcmakeいらんわ
うまくクロス環境みつけてくれないこと多いし

**デフォルトの名無しさん** · 2019/08/24(土) 09:02:17.39

>>625
cmakeとかautomake系のツールのコンセプトはできるだけ分けないで書けるように
ってところではあるが、まあ実際はそれぞれの環境用に色々やるのと大して変わらん。
少なくともデバッグするときはその環境毎のビルドがわかってないとほぼ詰むし。
なんだかんだでまずlinux系統でmakeになれるのが近道だとは思うけどね。
あれでヘッダー依存の取り扱いがしっかり書けるようになれば大抵のビルドシステムにも慣れるだろう。

**デフォルトの名無しさん** · 2019/08/24(土) 09:18:12.19

最終的にクロスプラットフォームでちゃんとやれることを目指すならmakeもmsbuildも
両方押さえておかなければならないわけで、どっちが先ってことはないと思うがな。

**デフォルトの名無しさん** · 2019/08/24(土) 20:42:19.22

makeのが圧倒的に情報調べるのが楽だろ。

**デフォルトの名無しさん** · 2019/08/24(土) 21:18:36.57

WSLが一般的になったら苦労は減るのだろうか

**デフォルトの名無しさん** · 2019/08/24(土) 22:40:38.50

- >>630と>>632に話の脈絡が全くない
- >>632 べつに楽な方から始めるのが良いという根拠もない
- というか>>630はmakeがわかれば他はもっと楽だという、逆のニュアンスだったんじゃないの？
- そもそもmsbuildの情報もMSDNで簡単に調べられるし

ツッコミどころ多すぎ。

>あれでヘッダー依存の取り扱いがしっかり書けるようになれば

いまどきlinuxでもそんなん手書きする奴はいないｗ

**デフォルトの名無しさん** · 2019/08/25(日) 12:27:30.33

makeじゃなくてmsbuild教える方がいいと思うならお前はそうしろ。
それが本当にいいと思ってんならな。
俺だったらmakeを教えるというだけの話だ。

**デフォルトの名無しさん** · 2019/08/25(日) 14:08:01.24

また支離滅裂なｗ
makeとmsbuildの優劣なんて話はしてないんだが、日本語不自由なのか？

>少なくともデバッグするときはその環境毎のビルドがわかってないとほぼ詰むし。

という理由でmakeを覚えなければならないと主張するなら、同じ理由でwindows環境向けには
msbuildを覚えておかなければ片手落ちだろうと指摘しただけ。

まぁどうせ上の理由も後付けで、cmakeを知らない爺が横からmakeを布教しようとしただけなんだろうが。

**デフォルトの名無しさん** · 2019/08/25(日) 15:35:39.92

makeの罠の多さは異常
絶対手で触りたくない

**デフォルトの名無しさん** · 2019/08/25(日) 15:51:39.75

手で触るもんじゃないけど
一度手で触っておかないと吐き出されたmakefileを見て何がおかしいか理解できない

**デフォルトの名無しさん** · 2019/08/26(月) 11:17:55.70

std::condition_variableを使って複数のスレッドが待ち状態の時、
notify_oneで一つだけスレッドロック解除した場合、解除されるスレッドに優先度はある？
例えば、一番最初に待ち状態に入ったスレッドのロックが解除されるとか。
それとも完全に実装依存？

**デフォルトの名無しさん** · 2019/08/26(月) 16:25:41.54

notify_one使ったことないけど解説読む限り実装依存に見える(待機中のスレッドからいずれか一つ、とかあるし)
順序あるならそう書かれると思う
曖昧ですまんけど

**デフォルトの名無しさん** · 2019/08/26(月) 19:23:22.50

実装定義だと思うけど、wait呼び出した順だと考えていいと思う

**デフォルトの名無しさん** · 2019/08/26(月) 20:31:47.24

俺は多分カーネルのスレッドのスケジューリングで
たまたま選ばれたやつが走ると思う
しらんけど

**デフォルトの名無しさん** · 2019/08/26(月) 22:58:04.80

流れ読まずに申し訳ございません、質問させてください。

非エンジニアのものなのですが、下記のようなオープンソースのコードを使って
メッセージのウェブアプリケーションを創ってみたいのですが、
一番手っ取り早い方法はどういう方法でしょうか？

漠然とした質問で申し訳ございません

▶Telegram
https://telegram.org/apps#source-code
▶Signal
https://github.com/signalapp
▶Rocket Chat
https://github.com/RocketChat/Rocket.Chat
▶Tox
https://github.com/Tox/tox.chat
▶Wire
https://github.com/wireapp/wire

**デフォルトの名無しさん** · 2019/08/26(月) 23:04:19.65

金で解決

**デフォルトの名無しさん** · 2019/08/26(月) 23:21:58.15

>>636
お前ほんとにmsbuildいじったことあるのか？
あんなクソなものを本気で使ってんの？
てかヘッダ依存解決くらい書けなきゃまともなビルドシステムなんて絶対組めねーよ。
こういう誤誘導を平気でするやつってどういう神経してんだろうな。。

**さまよえる蟻人間** ◆T6xkBnTXz7B0 · 2019/08/26(月) 23:25:34.58

>>643
ウェブアプリなのにC++スレで質問するの？根本的に間違ってるんじゃない？

**デフォルトの名無しさん** · 2019/08/27(火) 00:16:27.36

最近C++を学び始めたのですが、
テンプレート引数の型をコンパイル時に文字列に変換する方法ってあるのでしょうか？

できればテンプレートの特殊化やプリプロセス命令を使わずに以下の用な感じでかければよいのですが

template<typename Type>
class Hoge
{
public:
static constexpr char* Text = Typeを文字列に変換して納入したい
};

**デフォルトの名無しさん** · 2019/08/27(火) 00:31:42.36

無理ゲー
あくまで自動にこだわるならtypeid使え。
自作クラスだけならクラス名を名乗るメンバ関数でも作っとけ

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

https://github.com/Manu343726/ctti

**デフォルトの名無しさん** · 2019/08/27(火) 08:26:10.70

>てかヘッダ依存解決くらい書けなきゃまともなビルドシステムなんて絶対組めねーよ。

いつの時代から来たんだよｗ
ソースに #include 書く度にいちいちMakefile書き換えんのか？

**デフォルトの名無しさん** · 2019/08/27(火) 08:40:44.27

>>646
初心者狩りしてるこいつ一人ww

**デフォルトの名無しさん** · 2019/08/27(火) 17:31:34.79

>>649
以前nameofとかいうライブラリ？が同じくgithubにあったけどどっちが便利かな
というかこの手のは他にもあるっぽいな

>>651
いや合ってると思うけど
ウェブなのかネイティブなのか、多分ごっちゃになってるだろうからまずそこを指摘すべき

**デフォルトの名無しさん** · 2019/08/27(火) 18:46:31.35

別にウェブだからって既存のブラウザ上で動くものという定義はあるまい
サーバーサイドもクライアントサイドも両方C++で作ればいい
そもそもブラウザだってC++で作られているんだから

**デフォルトの名無しさん** · 2019/08/27(火) 19:25:57.30

>>653
両方自分で作るならもっとシンプルなプロトコルでやるよ

**デフォルトの名無しさん** · 2019/08/27(火) 21:20:18.36

typeidってPFで戻ってくる値が違うからテスト書くとき気をつけるん

**デフォルトの名無しさん** · 2019/08/28(水) 08:42:46.33

>>650
書き換えなくていいように書けるようにするってことだよバカ。
てか依存をしっかり見るって意味じゃヘッダを意識するってのは
相当大事なんだがな。
タスク管理を意識した場合、どんなレイヤーで仕事する場合でも重要になる。

**デフォルトの名無しさん** · 2019/08/28(水) 08:50:01.49

てか想像以上にビルド周りの技術ってc+11から入った輩は理解してないのな。。
またクソシステムの再生産が10年単位で続きそうだわ。。

**デフォルトの名無しさん** · 2019/08/28(水) 10:10:28.35

そりゃこのスレでも
「閃いた！stdを usingすれば文字を打つのが少なくなるよ！」って宣う輩がいるくらいだし

**デフォルトの名無しさん** · 2019/08/28(水) 10:16:52.21

趣味でc++のパズルにはまってる人と
仕事で生産的に使いたい人とでは
言語に期待するものが違うからね
区別しないと

**デフォルトの名無しさん** · 2019/08/28(水) 10:25:14.14

このビルド周りのクソ仕様のせいで年々インタプリタ型に人が流れていくんだわ

**デフォルトの名無しさん** · 2019/08/28(水) 11:21:15.45

VS使ってるからmakeとかさっぱりです

**デフォルトの名無しさん** · 2019/08/28(水) 11:48:22.94

新モジュールシステム対応で改善されるはず…
https://cpprefjp.github.io/lang/cpp20/modules.html

**デフォルトの名無しさん** · 2019/08/28(水) 14:10:32.76

そのうちC++ライブラリ用リポジトリとかC++用パッケージマネージャとか作りはじめそう

**デフォルトの名無しさん** · 2019/08/28(水) 15:22:40.67

車輪の再発明が好きなやつが多すぎてウンザリする
道具ばっか作ってどうすんだ
道具つかって絵描いたり家建築したりするのが仕事なのに

**デフォルトの名無しさん** · 2019/08/28(水) 17:41:27.32

仕事じゃなくて趣味だからな。

**デフォルトの名無しさん** · 2019/08/28(水) 18:52:20.58

makefileなんて十数年触ってないしもう忘れたけど
>>656-657には同意するわ
依存関係も考えた上で設計&利用しないとコンパイル時間の増大とかに全く対処できなくなる
新しい機能には飛びつくわりに古い部分(しかも無くなってるわけではない)をおざなりにするのはあかん