C++相談室 part135

2018/03/31(土) 20:20:06.25

次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512

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

前スレ
C++相談室 part134
http://mevius.5ch.net/test/read.cgi/tech/1516406742/

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

■長いソースを貼るときはここへ。■
　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

2018/05/12(土) 14:27:22.97

使うモジュールの差を言語で言うから話が紛れる

で、
君の定義であるごく一般的な記述を行った場合の話であれば

C++の方が速いこともあるしCの方が速いこともある

C++はテンプレートによって専用のコードをたくさん作る
当然汎用バイナリよりも専用バイナリの方が最適化がかかりやすいし、
変数よりも即値の方が速いことも多い

C++例外処理も有効で、
これによって処理が速くなる場合がある

2018/05/12(土) 14:27:42.28

>>686
gcc unko.c -O3でやってる

2018/05/12(土) 14:29:31.07

>>685
> 内容には無関係で単に
Linus全否定かよ。

2018/05/12(土) 14:30:30.03

>>682
オールゼロでクイックソート？
それは...

2018/05/12(土) 14:35:18.35

>>687
> 君の定義であるごく一般的な記述を行った場合の話であれば
> C++の方が速いこともあるしCの方が速いこともある
ねーよ。
実例挙げてみ？
それって単なるコンパイラの適性であって、コード自体の速度ではないだろ。

C++とCの本質的な速度差ってのは絶対にひっくり返らないものであって、
例えば、スマポを使っている限り参照ポインタを管理する分だけ遅くなる、というもの。
コンパイラがどう進化しても、「０」「ADDまたはDEC命令」の差はひっくり返らないんだよ。

> C++例外処理も有効で、
> これによって処理が速くなる場合がある
ねーよ。Cは最初から全部noexceptだ。

2018/05/12(土) 14:35:49.71

ソートって

メモリサイズ
比較コスト
コピーコスト
キャッシュサイズ
...

こんなんで結果(時間)が大きく異なるんだよね
クイックソートだと
データの並び順でもたまたま選んだピボット値でも変わる

1個の場合を比較してもあまり意味が無いぞ

2018/05/12(土) 14:36:05.87

clでやってみたら期待どおりの結果になった
>>677 1.789[sec]
>>678 0.623[sec]

最適化は/Ox

2018/05/12(土) 14:36:46.83

>>690
ああ、それは確かに
テストデータをまじめに作るか。。。

2018/05/12(土) 14:37:45.07

>>688
となるとアセンブラを確認するしかないね。
(いいサイトはあったはずだが、普段使わんから忘れた)

2018/05/12(土) 14:37:57.15

>>689
ん？　なんで？

2018/05/12(土) 14:44:25.97

>>693
それさ、以下の3条件でやってみ。

1) Cのコード(677)を、Cコンパイラ
2) Cのコード(677)を、C++コンパイラ ←追加
3) C++のコー(678)を、C++コンパイラ

Cコンパイラってポインタ周りは最適化をかけないから、多分、
速度差はコンパイラ起因であって、コード起因では無いと思う。

2018/05/12(土) 14:45:53.71

>>696
> (b) 自分が書いているのは実はCだと気がついていないC++バカ
> https://cpplover.blogspot.jp/2013/05/linus-torvalsc.html
君の定義が正しければ、上記(b)の定義が出来なくなるだろ。

2018/05/12(土) 14:46:34.72

>>691
C++が遅くなる例だけあげてC++が遅いって言ってもねえ

C++が速い例

double p = 1.;
int n;
for (n = 1 ; ; n++){
p *= n;
}

C++だと例外処理をつかって、いつオーバーフローするかわかるんだけど
例外を使わないとどういうコードになるかねえ？

---
Cで普通に汎用vectorを作るとすると
普通は汎用バイナリで作ることになるんで
関数ポインタを経由する事になっちゃうけど
C++のテンプレートだとだとそれぞれ専用なんで
関数コールが速いよね
アドレス計算も即値の乗算だから色々なテクニックが使える

2018/05/12(土) 14:47:13.55

わりい、ちょっと離席する

2018/05/12(土) 14:49:16.03

>>699
> C++が速い例
Java出身か？死ね

2018/05/12(土) 14:51:30.31

C++だとコンテナを使ってまともなソートを簡単に書けるけど
Cだと面倒だからバカソート
ってのも普通にある
要素数が少なければ意図的にやったりもする

一般的なコードではCの方が速い事の方が多い
ってくらいの主張にしとけば良いものを
強い主張をしちゃうから

2018/05/12(土) 14:53:13.25

>>701
ん？
良くわからんが負け宣言てことでいいのかな？

2018/05/12(土) 14:55:06.52

>>684
何を言ってるのか意味不明すぎる
よほど感覚が独自なんだろうな w

2018/05/12(土) 14:56:22.02

>>699
おっとすまん、ポインタアクセスでのメモリオーバーフローと勘違いしてた。

doubleの無限大の例外って事？
俺はそっちには詳しくないが、浮動小数点例外をソフトウェアで検出するのなら同じだし、
ハードウェアでの検出なら割り込みがかかるだけで、速度的にはこれまた同じだが。

vectorについては完全に君の勘違いだぞ。
Cではそれぞれ専用の物を作るのが基本であり、それを一つにかけるようにしたのがテンプレートだ。
多分、理解の仕方が逆だ。

2018/05/12(土) 14:57:30.76

>>699
> Cで普通に汎用vectorを作るとすると
> 普通は汎用バイナリで作ることになるんで
速度云々議論してるところでそんなことする奴はバカって言われてもしょうがないと思う

2018/05/12(土) 15:04:23.09

>>705
> ハードウェアでの検出なら割り込みがかかるだけで、速度的にはこれまた同じだが。
Cだと言語の範疇ではその割り込みを処理できない
なのでif文とかでオーバーフローするのを検出するとかが必要
って話だろ

2018/05/12(土) 15:07:59.44

>>707
> if文とかでオーバーフローするのを検出するとかが必要
ほう。ならそのコードを書いてみ。
そしたらそのコードの中でオーバーフローするから無限ループだね。
そんな言語が実用だったとでも？

2018/05/12(土) 15:15:00.22

>>705
例外については「お前は頭が悪すぎて会話にならん」とだけ

コンテナは
「C++の方が遅い例だけ扱って、速い例は自分の想定と違う」
という主張を続けるならお前と会話しても無意味だ

2018/05/12(土) 15:16:02.69

IDが変わってしまった
まあそんな事はどうでもいいか

2018/05/12(土) 15:18:43.30

ちなみに速度比較についてはいろんな人が様々やってるけど、
俺的にまあ公平だと思えるのはこれだね。俺の体感ともだいたい一致する。
おれはC++は1.1-1.3位かと思っているけど。

> C 1.00
> C++ 1.56
> Java 1.89
> C# 3.14
> https://jaxenter.com/wp-content/uploads/2017/09/energy-efficient-languages-768x689.png
> https://jaxenter.com/energy-efficient-programming-languages-137264.html

C++の機能をバリバリに使ったら、そりゃJavaと大して変わらんだろ、ということになるし。
スマポってのは良くできたGCとコストはほぼ同じだし。（GCは全自動なだけ）
Javaは以前は3程度だったが、ゴリゴリチューニングしてきているらしい。

2018/05/12(土) 15:19:13.36

>>706
速度優先のコード前提ってことなら
保護されまくった高機能汎用コンテナを使うこと自体アホってことになるねえ

さらに条件を加えちゃってもう

2018/05/12(土) 15:19:20.53

>>709
僕は知りません、まで読んだ。

**デフォルトの名無しさん** · 2018/05/12(土) 15:20:34.21

>>708
なんで喧嘩腰なのかがよくわからないけど、
C言語では「n <= DBL_MAX」というif文が必要ってことだろ？

double p = 1.;
int n;
for (n = 1 ; n < DBL_MAX; n++){
p *= n;
}

2018/05/12(土) 15:23:37.01

>>714
いやオーバーフローするのは p だろ。

と思ったが、もしかして n の方なのか？

**デフォルトの名無しさん** · 2018/05/12(土) 15:33:27.39

>>715
なんでもない、忘れて＞＜

2018/05/12(土) 15:48:51.69

>>716
通じたようで何より。

だからオーバーフローの検出はソフトウェアでは辛くて、通常はハードウェアのはずだ。
そしてその場合は割り込みとなり、Cの場合は割り込みハンドラにコードを書くことになる。
C++の場合は『そこから例外処理ルーチンまで引っ張ってきてくれるコード』をコンパイラが用意し、
ユーザーのcatchコードを実行する。つまり、上記『』内コードでラップされてる分だけ遅い。
（実際にはラップだけではなくスタックウォークも行うから相当遅いはずだが）

なんだが、実際俺はゼロ割例外しか見てないからオーバーフローについてはよくは知らん。
ハードウェア的には上記の動作になる。
一般的にはオーバーフロー例外は出ない環境（無限大に貼り付けるだけ）で使うのではないかと。

Cではアホみたいにゼロ割チェックやってるよ。
これはC++でも同じだと思うが、C++erはやらないのが作法なのか？
とはいえ、ゼロ割はCMP+Brachであり、通常は分岐しないから、x86ではほぼゼロコストだ。
割り込みは関数呼び出し自体が遅くなるから、結局これもCの方が速いはずだが。

2018/05/12(土) 16:03:54.80

>>712
お前話の流れが読めてないだろ w
>>638から読み直せ、バカ

2018/05/12(土) 16:11:14.40

overflowてexception吐くんだっけか

2018/05/12(土) 16:35:26.68

>>708
バカはこれだから w
isfinite( ) マクロとかも知らんのかよ

◆QZaw55cn4c (ﾜｯﾁｮｲ 6360-bFqk) · 2018/05/12(土) 16:40:25.40

>>717
オーバーフローで例外や割り込みが起動することはないのでは？
普通、無符号ならキャリー、符号有りならオーバーフローのどっちかのフラグで判定するかと

2018/05/12(土) 17:14:24.19

unsigned long long array[100000000];
↑
ここに同じファイルから乱数を読み込んで比較してみた

clのオプションは /Ox /arch:AVX
gccのオプションは -O3 -mtune=sandybridge

qsort
cl 27.171[sec]
gcc 26.139[sec]

std::sort

2018/05/12(土) 17:16:00.99

途中で書き込まれてしまった
unsigned long long array[100000000];
↑
ここに同じファイルから乱数を読み込んで比較してみた

clのオプションは /Ox /arch:AVX
gccのオプションは -O3 -mtune=sandybridge

qsort
cl 27.171[sec]
gcc 26.139[sec]

std::sort
cl 13.456[sec]
gcc 9.103[sec]

おまけ
std::sortにstd::execution::parを指定してみた
cl 3.288[sec]
gcc 未実装

2018/05/12(土) 17:16:40.49

>>690が正解だったね

2018/05/12(土) 17:49:15.49

>>698
そこの２通目に箇条書きしてある部分は
1992年当時に俺が思っていたことに近い

・例外がクソ
うん、マジクソだ
C++11以後マシになったが下痢が治ったという程度

・newいらねー
演算子newを初めて聞いた瞬間、
mallocの設計理念が大声でわめき立てた
C++11以後ブーイングが更にエスカレートした

・キーワードclassいらねー
禿自身が認めやがった

・・・しかし、それがなぜ>>685への反駁に引用されるのかがわからん

2018/05/12(土) 18:15:21.20

>>721
大抵のプロセッサの浮動小数点ユニットにはオーバーフローしたら例外を発生させる機能がある
それを有効にしてるかどうかは環境による
あとC言語の話で割込ハンドラーとか言ってる>>717は単なる知ったかなのでスルーした方がいい

◆QZaw55cn4c (ﾜｯﾁｮｲ 6360-bFqk) · 2018/05/12(土) 18:29:10.59

>>726
＞大抵のプロセッサの浮動小数点ユニットには
「浮動小数点ユニット」なんですね、ここで確認しておきます。

＞オーバーフローしたら例外を発生させる
演算結果が　±inf になることを「オーバーフロー」と言うのですか？ちょっと耳慣れないですね

>>726
＞C言語の話で割込ハンドラー
lsi-c ver3, MS-C ver6 あたりでは、そういうのもあったと記憶してます、 matherr() ですね
だから >>717 はあながち間違いとはいいきれない面もあります

2018/05/12(土) 18:40:33.53

>>725
世間では「どちらのコンパイラを使うか」ではなく、
「どちらのスタイルで書いているか」でCとC++を区別してるんだよ。

2018/05/12(土) 18:42:16.14

>>727
> 演算結果が　±inf になることを「オーバーフロー」と言うのですか？ちょっと耳慣れないですね
それ反対、オーバーフローしたら結果をinfにしてるだけ

◆QZaw55cn4c (ﾜｯﾁｮｲ 6360-bFqk) · 2018/05/12(土) 18:49:16.74

>>729
inf も NaN も浮動小数点表現の中にあるので「オーバーフロー」と呼びにくい、と思っています、まあ人それぞれ

2018/05/12(土) 19:04:56.38

>>730
だから誰もinfがオーバーフローとは言ってないだろ
オーバーフローしたらそれっぽい値としてinfを入れてるだけ

2018/05/12(土) 19:24:22.69

>>728
それなら
Cスタイル、C++スタイル
と言えば良い

CかC++かは当然コンパイラで決まる
C++は元々上位互換を目標に作られた物だ

2018/05/12(土) 19:29:38.17

>>728
お前の変な世間はどうでもいい

2018/05/12(土) 19:48:04.17

>>732
> C++は元々上位互換を目標に作られた物だ
そうだ。そしてだからこそ、スタイルで区別されるんだよ。

元々C++はCの完全上位互換だった。
だから君らの定義なら、C++が登場したときから全てのCは消滅し、C++になっているはずだろ。
実際はそうじゃない。
「○○のコードはCで書かれています」
「○○のコードはC++で書かれています」というのは、
世間では俺の言った定義(>>676)で使われてる。

その後、CとC++が仕様的に分離してしまったから、
今現在はCコンパイラで通るコードがC++コンパイラで通らないケースが存在する。
だから今は明確に「どちらのコンパイラを使うか」を想定しておく必要があるが、
それもコーナーケースで、
大半の「Cのコード」はC++コンパイラでもそのまま通る。

お前らがC++信者でC++の範囲を広く取りたいのは分かるが、世間はそうじゃない。

C++がCの仕様を全て取り込んだら、
お前らにとってはCは消滅、全てはC++になり、お前らは幸せになれるだろうさ。
ただ、その後も世間はCとC++を引き続き区別するだろうよ。

2018/05/12(土) 20:09:12.78

お前用語の定義の説明とかどうでもいい
スタイルの意味ならスタイルと書け

2018/05/12(土) 20:09:24.63

>>734
それは嘘だなぁ
extern "C"が無いとCライクに見えるオブジェクトを吐かない事が常となっているC++(コンパイラ)について、いくらpure Cライクなコードを書いてもpure Cでないextern "C"を書かないとCライクに見えるオブジェクトは吐けないってそれはもうC++でしょう

他の内容にも誤りがあって君の世間ではCライクなコードであればCで書いたと宣言していいらしいけど、少しでも世間のOSSのコードを見て回れば良いよ
Cで書かれているのはCだから

2018/05/12(土) 20:30:38.36

お前らが誤解したままでいるのはお前らの自由だが、
お前らの定義だと、CとObjective-Cを区別できないだろ。
あれはCの完全上位互換で、Cコードそのまま食えるらしいからね。

お前らも少し考えれば自分で矛盾に気づけるはずだが。

2018/05/12(土) 20:58:42.38

>>734
それは言い過ぎでしょ。
流石にそれは、世間を知らなすぎ、と言われても仕方ない意見にみえてきたなあ。。。

2018/05/12(土) 21:57:33.16

ならもうちょっと分かりやすい説明をしてやる。

>>677-678について、お前らの定義では『コード』について議論できないだろ。

俺の定義では、677は「Ｃのコード」で、678は「C++のコード」だ。コンパイラに依らない。
お前らの定義では、678は明確に「C++のコード」だが、677については、
「Cコンパイラを通した場合、677はCのコード」
「C++コンパイラを通した場合、677はC++のコード」
になってしまうだろ。
それだと、CとC++の『コード』の速度比較自体が定義できないだろ。

677をCコンパイラを通した場合とC++コンパイラを通した場合の速度差は、
「コードの差」ではなく、「コンパイラの差」なんだよ。
当たり前だろ。

というか、C++erもここまでレベルが落ちたのか。世も末だな。

2018/05/12(土) 22:16:57.78

std::filesystemで片方のスレッドでファイルを出力し
もう片方のスレッドでファイルが存在していたら読み込むというプログラムを書いた場合
出力中に存在すると判定されて読み込んでしまいそうですが、
そんなことないでしょうか？
もし読み込んでしまう場合、自力でフラグ管理かMutexを使うなどして
判定する以外の方法はあるでしょうか？

2018/05/12(土) 23:29:24.63

>>739
お前が考えた定義とかどうでも良いって言ってるの

2018/05/12(土) 23:53:40.44

というか何でお前らそんなに必死なんだ？
俺の言ってる定義が世間一般の定義だよ。
そうじゃなきゃ『コード』の善し悪しの議論が出来ないだろ。自明だと思うが。

繰り返すが、C++がCよりも遅いのは事実で、それもググレばいくらでも出てくるだろ。
ただこれはC++そのものよりもオブジェクト指向の弊害だが。
http://chrismdp.com/2015/04/how-i-doubled-the-speed-of-my-game-by-giving-up-on-c-plus-plus/
https://www.quora.com/Why-is-object-oriented-programming-OOP-slower-than-procedural

逆に言えば、C++の機能をふんだんに使ったとして、Javaに対する速度優位がどれだけあると思ってるの？
C++で世界が再統一されることは、今のC++の仕様/方向性ではあり得ない。C++ではCを殺しきれない。
だからRustが生まれた。
>>711の表を信じるなら、RustはCの代替としてはC++以上に上手く行ってる。

2018/05/12(土) 23:56:27.27

お前の定義じゃないと議論が出来ないのは
おまえがアホだから

2018/05/13(日) 00:02:56.89

定義の布教なんかより技術的な会話をしろよ

2018/05/13(日) 00:03:10.09

必死なのはどちらなんだろう…

2018/05/13(日) 00:20:47.86

C++スレらしい流れだと思うよ

◆QZaw55cn4c (ﾜｯﾁｮｲ 6360-bFqk) · 2018/05/13(日) 00:59:58.71

面白くていいじゃないですかぁ…
ここで linus メールをコピペ（省略）

◆QZaw55cn4c (ﾜｯﾁｮｲ 6360-bFqk) · 2018/05/13(日) 01:17:46.49

>>742
面白い表ですね
つい C# とか lisp の立ち位置を確認してしまった…

2018/05/13(日) 08:12:09.87

>>739
だからお前のオレオレ定義なんてどうでもいい

そもそも>>638みたいな話でC++→Cで全面書き換えなんてする奴はいないだろ
まともなプログラマーならボトルネックを見つけてその部分を書き換える

例えば１つのファイルに関数f1()とf2()があってf2()がボトルネックだからC++からCの範囲で動くようなコードに書き換えたとする
お前はそのファイルの記述言語は何て言うんだよ？
関数毎に記述言語が違うとか言い出すのかよ w

2018/05/13(日) 08:18:26.86

>>740
> 出力中に存在すると判定されて読み込んでしまいそうですが、
> そんなことないでしょうか？
そりゃ普通にそんなことあるだろ

> もし読み込んでしまう場合、自力でフラグ管理かMutexを使うなどして
> 判定する以外の方法はあるでしょうか？
そもそも何をしたいのよ？
出力完了してから読みたいだけなら出力完了してから読み込む側のスレッド起動するとかする方法もあるだろうし

2018/05/13(日) 09:30:39.74

>>749
お前がIDコロコロしてまでも定義にこだわる理由が分からん。

お前の定義なら、仮に全面インラインアセンブラで記述してあっても、
Cコンパイラを通したらそれは「Cのコード」であり、
C++コンパイラを通したらそれは「C++のコード」になり、
Objective-Cコンパイラを通したらそれは「Objective-Cのコード」と言うんだろ。
そんな定義の奴はいない。それは「アセンブラ」と言うんだよ。

ただこの定義はもういい。
君は間違いを認めないようだし、仮に俺が間違っていたとしても、
お互いの認識のズレは確認できたのだからそれでいいだろ。
そして>>638は最初からそう言っているだけだ。

お前は「コンパイル単位」でしか言語を規定できないからおかしな事になっている。
世間は「コード単位」でも言語を規定する。だから、お前が
> f2()がボトルネックだからC++からCの範囲で動くようなコードに書き換え
と言うのを、世間では「f2()をCコードに書き換え」と言うんだよ。
仮にお前の定義が正しくても、これを日常的にやるようなら、じきに略されて
俺（世間）の言い方に落ち着くのも分かるだろ。

だから>>638は最初から、お前の言葉で言う、
> f2()がボトルネックだからC++からCの範囲で動くようなコードに書き換える
「f2()がボトルネックだからC++からアセンブラの範囲で動くようなコードに書き換える」事を
> もっと速くしたい所をCやasmで書く
と表現している。元々「コンパイル」単位ではなく、「コード」単位なんだよ。
その「コード」について議論するのに、「コンパイル」単位を持ち出すのはおかしいだろ。
「速くしたい『所』」ってのは一部限定って事を明示してるだろ。
お前はどうしても認めないようだが。

お前は根本的に考え方がおかしい。それではまともな議論が成立しないだろ。
議論している粒度に合わせた言葉を使え。

2018/05/13(日) 09:51:06.22

>>751
> ただこの定義はもういい。
> 君は間違いを認めないようだし、仮に俺が間違っていたとしても、
> お互いの認識のズレは確認できたのだからそれでいいだろ。
いきなり弱気になってて笑うわ w

**740** (ﾏｸﾄﾞ FF91-uCqk) · 2018/05/13(日) 10:01:51.37

自己解決しました。
仮の名前でファイルを書き出してからリネームすれば書き込み中か書き込み済みか
判定する処理をなくせるみたいでした。

2018/05/13(日) 11:07:48.71

>>751
コンパイラが変わらない単なる最適化で
C++からCにする
なんて言わないから普通
少なくともエンジニアの会話では無い

簡単にいう場合は「最適化」「チューニング」だし
詳しくいう場合は中身を具体的に言う

頭の悪い文系を騙すのには使えるのかもしれないけど

2018/05/13(日) 11:09:34.85

C言語風なコード
と
C言語のコード

全く意味が違う

**638** (ﾜｯﾁｮｲ 1be7-1eaZ) · 2018/05/13(日) 11:24:15.00

「C++で書く」→カジュアルにSTLとか使って読みやすく書く
「Cやasmで書く」→キャッシュやSIMDとか低級に考慮してガリガリ最適化する

くらいの軽い気持ちで書いただけなのに紛糾しすぎててワイ将困惑

2018/05/13(日) 12:17:41.91

話が長い上にどうでもよすぎる

2018/05/13(日) 12:26:54.36

またいつものキチガイか

2018/05/13(日) 12:43:30.13

>>756
おまえさんの頭がC++03のまま更新が止まってしまっていることはわかった

◆QZaw55cn4c (ﾜｯﾁｮｲ 6360-bFqk) · 2018/05/13(日) 12:46:19.41

>>759
そう判断した理由は？

2018/05/13(日) 12:51:49.36

C++11以後の「低級」を知らんだろ

2018/05/13(日) 13:01:15.34

C++xx
この末尾のへんなナンバリングが施されるようになったのっていつ頃から？

2018/05/13(日) 14:22:28.62

>>762
元々はC++09を狙ってたらしいから2008年頃じゃね？

◆QZaw55cn4c (ﾜｯﾁｮｲ 6360-bFqk) · 2018/05/13(日) 14:53:37.16

>>761
具体的に

2018/05/13(日) 15:27:50.96

>>764
人に聞くのは知らないからだな

2018/05/13(日) 15:47:31.87

>>759
STLが03から入ったと思ってんのか

あと
＞Cコンパイラってポインタ周りは最適化をかけないから、多分、
＞速度差はコンパイラ起因であって
こんなこと言ってる時点でID:PbE4ojLD0の話は聞くに値しない

2018/05/13(日) 16:22:20.14

>>766
あの流れからどうやってSTLが03からという話になったんだ？

2018/05/13(日) 17:44:42.77

>>756
馬鹿につき合ってすまんかった。

少なくとも俺とLinusは君と同じ定義で使ってるよ。俺の認識では世間もそう。
俺はこれでこれまで話が通じなかったことはないから。
おそらくはCをやらずにC++だけやってる世代と、
必ずCをやったうえでC++に進んだ世代の違いだ。
ゆとりだけで閉じてる世界では、彼らの主張する定義なのかもしれん。

ただまあ、話を聞いてる限り、こいつらは色々と無知だし、無知なことに無自覚だね。
まあもういいが。
自分が知らないだけのことをすべて間違いだと断定しているようでは上達しない。
C++erもここまでゆとり化が進んだのは残念だ。

2018/05/13(日) 19:37:46.91

本当に通じていたのかな？
いわゆるフツーの人達は、めんどくさいから適当に話し合わせてテキトーに打ち切るものだが…

2018/05/13(日) 20:05:09.29

ついでだからもう少し書いておいてやるよ。

ゆとりC++erが「C++は速い」ということにしたがるのは、C++「言語」以下の解像度がないからだ。
「C++コンパイラさえ使えばおｋ」になってくれてないと困るからこそ、そこに異常にこだわる。
(他言語でも同様に、低位実装を直感的に推測できない馬鹿はこの傾向がある）

お前らは>>722-723の結果、同じデータ構造で同じアルゴリズムを適用した物に対し、
速度差が出た場合にそれを「言語の差」と言い張るようだが、
それは明確な間違いだ。ただの不勉強でしかない。
実際、それだとそれ以上の最適化は出来ないだろ。
C出身者なら、必要ならasm書いてチューニングすることも出来る。

現在C++は失敗しつつある。
それはRustを見ても明らかだ。以下ページを見てみろ。
https://imoz.jp/note/rust-functions.html
スマポ(ｷﾘｯな連中にとってはC++よりもRustの方が明らかにいい言語だろ。（後発なので当たり前だが）

C++だけにすがるのは止めとけ。
もうそういう時代じゃないし、C++はそれを満たせる言語ではない。

2018/05/13(日) 20:17:51.87

別にC++とCの宗教論争に加わるつもりはないが、
お前qsortがstd::sortより遅くなりがちな理由わかってないだろ
アセンブラ使わんでも自分で書きゃCでも同等の速度は出る
（というかVCの最適化にハンドアセンブルで本当に勝てるんか？こいつ）

＞CよりもC++の方が速くなるコードの方があり得ないと思うが。
＞CのほうがC++より遅いケース出してみろ。ないから。
調べもせずにこんな決めつけを書く低レベルさ以前に
これをC++のスレで書くお前はどう見てもただの荒らしだから。

2018/05/13(日) 20:53:01.09

>>771
お前は根本的に勘違いしている。
出発点は自前のコードでもいいが、逆アセンブル結果でもいいんだから、
改善できなくとも、遅くなることはあり得ない。

アセンブラを読めない君らでは、これは無理だ。
そして、遅くなる可能性の方が高いからやらないってのは、
馬鹿な君らなりの対処法としては正しい。

まあ、C++スレではC++マンセーしないと荒らしだ、ってのは理解した。
C++erがそこまで落ちぶれたのは残念だが、俺は去るよ。

2018/05/13(日) 20:57:13.19

それぞれの言語の良くある使い方であれば
Cの方が速いコードもC++の方が速いコードも
どちらも存在する

同じ処理を同じように書けば普通は同じ速度
(ただし、一部細かい例外あり)

2018/05/13(日) 20:59:07.22

一般的な使い方では
C++の方が開発効率が高く
Cの方がバイナリの性能が高い事が多い
(もちろん逆になる要素もある)

2018/05/13(日) 21:06:47.71

>>772
以前ここに書いたこともあるけど、最近ET＋simd（SSE、NEONのイントリンシック）で
ゲーム用の自前の線形代数ライブラリとか作ったんで
＞アセンブラを読めない君ら
残念ながらこれは当てはまらないよｗ
どれだけ逆アセ読んで比較したか・・・・

＞C++マンセーしないと
お前が”正しい批判をしてれば”荒れてないんだよ

ついでに言えば、
＞「C++で書く」→カジュアルにSTLとか
STLをカジュアルとか呼ぶ辺り、最近のC++界隈は
「流行に流されて自分で考えることを放棄する」という、かつてJavaの流行に荒らされた時代と
同じ愚を犯してるな、とは思うけどねぇ
C++er憎し、では色々と話がおかしくなるよ

2018/05/13(日) 21:07:47.84

同じ処理を同じ動作で記述出来ない例

Cの可変長配列
C++の例外処理

2018/05/13(日) 21:09:03.49

もうアホらしくなって途中離脱したけど
例えば関数内のループで使ってるstd::unique_ptr が遅いからその部分だけ生ポインタに書き換えたら ID:tSRcUD9w0 は何言語で書いたって言うんだろ？
って言うのはちょっと気にはなる
まあまた明後日の長文書くだけだと思うけど w

2018/05/13(日) 21:32:59.83

禿は神。
禿4はバイブル。

2018/05/13(日) 21:41:37.55

禿５マダー？(tntn

2018/05/13(日) 22:13:01.62

>>775
> どれだけ逆アセ読んで比較したか・・・・
ならコンパイラ出力コードが手書きアセンブラと比べてどれだけ糞かも知ってるはずだ。
それでその言い方には矛盾を感じるけどね。

> STLをカジュアルとか呼ぶ辺り、最近のC++界隈は
その発言は俺ではないが、
基本的には抽象度を上げるのは簡単にプログラミングする為であって、
「カジュアル」という表現は妥当だ。
Cみたいに全部手でゴリゴリ書く意味なんて無い。
速度が問題ない部分は出来るだけ手抜きすべきだ。STLがそれに適しているのなら使えばいい。

ただ、「STL使わなくてもどうとでもなる奴が手抜きでSTLを使う」のと、
「STLを使わないと何も出来ない連中がSTLを使う」のは全然意味が違う。
とはいえ、俺は後者が前者になるべきだとは思ってない。
ただ、後者ならC++ではなくJavaやC#を使った方が妥当だとは思うが。

君が見落としているのは、STLをカジュアルと呼ぶ連中は、
基本的に、STLを使わずに最速な実装が出来るものの、面倒なので、
「手抜き」を「カジュアル」と言い換えてごまかしているだけだということだ。
連中は君みたいにSTLが無いと何も出来ない馬鹿ではないんだよ。

> C++er憎し、では色々と話がおかしくなるよ
これは違うぞ。俺は無知なくせにデタラメを言い張るゆとりは死ねと思っているだけだ。
ただし、お前が無知のままで死ぬ権利は尊重するので、
有用な情報は書かないようにするが。

2018/05/13(日) 22:14:29.75

キチガイにさわるな

2018/05/13(日) 22:15:45.94

密度が低い

**デフォルトの名無しさん** · 2018/05/13(日) 22:19:54.88

>>772
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。

2018/05/13(日) 22:28:00.02

吐いた唾は呑ませんぞ

2018/05/13(日) 23:48:52.64

>>780
> ならコンパイラ出力コードが手書きアセンブラと比べてどれだけ糞かも知ってるはずだ。
爺いは早めに滅びればいいのに

2018/05/14(月) 00:21:52.22

constexpr+UCS=ニューパラダイムのはずだったんだがなぁ。
コンパイルタイムは夢がある。