C++相談室 part134

2018/01/20(土) 09:05:42.21

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

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

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

このスレもよろしくね。
【初心者歓迎】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/01/20(土) 09:07:45.45

STLつかうと一気に実行ファイルサイズが10倍に?！

環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない

すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。

C1010: ﾌﾟﾘｺﾝﾊﾟｲﾙ済みﾍｯﾀﾞｰの検索中に予期しない EOF を検出しました。
とかいうエラーが出るんだけどこれってどうすればいいの？

#include <stdafx.h>
後死ね。

言葉が悪いな。それで教えているつもりか。
まぁヒントぐらいにはなったな。
うむごくろう。

いつまでこの糞テンプレ張り続けるんだおい

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

2018/01/20(土) 09:24:34.73

前スレのvectorのsize_tの質問した者だけど

実際gprofでvectorの[]が重い原因になってることを確認してる
次に重い原因がイテレータの比較なんだけど

2018/01/20(土) 09:35:10.31

>>3
> 実際gprofでvectorの[]が重い原因になってることを確認してる
どんな確認したのか知らんけど、確認しててあんな質問してるなら単なるバカとしか思えないが...

2018/01/20(土) 09:50:30.10

またトンデモな使い方をしているのだろうな

2018/01/20(土) 11:02:33.41

メモリ帯域が律速になる処理はわりとあるので
大容量のデータを処理してるならおかしくはない

キャッシュ効かないメモリアクセスするコストに比べたら整数の拡張など微々たるもんだ

2018/01/20(土) 11:46:34.01

>>1乙
↓前スレの続き
std::vector<double> vec((size_t)1000);
...
size_t sz = vec.size();
for (int i = 0; i < (int)sz; ++i) {
　cout << i << " " << vec[i] << "\n";
}
の方がiをsize_tにするよりループ命令の部分が軽量化されることにより早いかも試練（x64では気のせい？
およびループ内で他に32 bit演算をやる場合、x64だと全てレジスタ上で賄える可能性が高まるから
速くなるかも試練、

結論：アセンブリコードを確認せよ

2018/01/20(土) 12:06:11.44

いやｽﾏﾝ
例が不適切やったわ；
ループ内でstd::coutみたいな重量のある関数呼び出しをしたら
「全てレジスタ上で賄える」とか
「キャッシュが有効活用で劇速化」とかも糞も無いな

2018/01/20(土) 12:31:55.30

noexceptってどういうときにつけたらいいですか。

2018/01/20(土) 13:45:44.65

>>3
[ ] が問題なら生ポ使えと書いてるんだけど無視？

2018/01/20(土) 13:51:38.35

>>8
重量の有り無しの前に
数値の文字列変換がsize_tとintじゃ違うだろ

それがなければどっちでも変わらんよ
64bit環境ならレジスタも64bitなんで

2018/01/20(土) 14:00:41.11

>>3
ん？
プロファイラの確認？
だとしたら[ ] が遅いんじゃなくてメモリの読み込みが実際に遅い可能性があるのでは？

そもそも、
[ ] が問題になるような小さなループで
[ ] の時間を正しく測れるのか？

いずれにしろ、生ポと比較してみるのが一番

2018/01/20(土) 14:02:23.47

メモリ帯域の問題なら
もっと大きな視野で最適化をしないとな

複数ループをくっつけてメモリアクセスを減らすとか
細切れに処理をしてキャッシュを効かすとか

2018/01/20(土) 14:04:10.50

[]が問題になるわけ無いだろ。ソースコード見たのかよ。
ナマポで書き直すなんて無意味。抜本的にアルゴリズム見直せ

2018/01/20(土) 14:05:12.48

あ、可能性だけで言えば
signedよりunsignedの方が速い
32bit から 64bit の符号拡張はコストが微妙にかかることもあるが、
ゼロ拡張はなにもしなくて良いから
レジスタの上位32bitは勝手にゼロになる

2018/01/20(土) 14:07:10.18

>>14
問題になることもある
君こそソースを見たかな？

2018/01/20(土) 14:50:38.90

>>15
今時のプロセッサでそんな奴見たことないけど？
妄想じゃないなら具体例よろしく

2018/01/20(土) 14:56:00.07

>>17
そんなやつって何だ？

符号拡張にコストがかかってゼロ拡張にコストがかからない例ならx86-64がそうだが

2018/01/20(土) 19:43:21.88

MOVSXもMOVZXも0クロックでは処理できないと思うんだが
ZXが0クロックで出来るってエビデンスはあるのかな？

https://stat.ameba.jp/user_images/20180105/17/genten-nippon/2b/2b/j/t02200142_0640041414105871600.jpg

2018/01/20(土) 20:07:30.62

32bitデータをレジスタに書き込んだら上位32bitが0クリアされることを言ってるんでしょ
コスト0って言うのはどうかと思うけど

2018/01/20(土) 20:30:37.09

質問させてください。
以下のコードで push_back 時にコピーコンストラクタが呼ばれます。
ttps://ideone.com/Zodd94

こちらとしては、下のページにあるように、ムーブコンストラクタが呼ばれることを期待しています。
ttps://qiita.com/_meki/items/90f9815a1e899593daa3

なぜムーブではなくてコピーになるのか、教えて頂けないでしょうか。