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

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

2018/01/20(土) 20:43:12.42

>>21
ムーブコンストラクタが定義されていないから

A(A &&) = default;
とでもしておけ。

2018/01/20(土) 20:49:44.91

>>22
ありがとうございます。解決しました。

2018/01/20(土) 21:07:26.00

追加で質問させてください。

コンパイラが自動生成する関数で、noexceptがついているのは
・デストラクタ
・ムーブコンストラクタ
・ムーブアサインメントオペレーター
の３つでよろしいでしょうか。

よろしくお願いします。

2018/01/20(土) 21:11:18.68

残り3つもデータメンバと基底クラスの同じものが全部noexceptなら付くよ

2018/01/20(土) 21:18:07.18

回答ありがとうございます。

データメンバと基底クラスのそれぞれのデフォルトコンストラクタが全て noexcept なら、
noexcept なデフォルトコンストラクタが自動生成される。
コピーコンストラクタ、コピーアサインメントオペレーターも同上
という理解でよろしいでしょうか。

また、その条件が成立しないときは、>>24で挙げた３つということになるのですしょうか。

よろしくお願いいたします。

2018/01/20(土) 21:36:13.58

>>26について自己解決しましたので、質問を取り下げます。
ありがとうございました。

2018/01/21(日) 11:30:18.34

>>16
noexceptなしに = defaultで宣言した場合はどうなるの？

2018/01/21(日) 11:32:32.53

>>28
>> 25の間違いです

2018/01/21(日) 13:25:22.34

もちろん宣言通りになる

2018/01/21(日) 13:32:54.03

>>30
thx

2018/01/21(日) 19:49:20.49

記述上 int* であるが、上書きされた場合に自動的に中身を delete してくれるポインタの入れ物を、
operator= のオーバーロードなしで定義できますか？

ちょっと変な質問なのだけど、native C++なら多分以下コードで出来る。

struct PatHead {
int* ptr;
int* operator=(int* value){
if (ptr) delete [] ptr;
ptr = value;
return value;
}
operator int*(){ return ptr;}
};

void test(){
PatHead ph[10]; // int* ph[10] と同じ記述で通るのがミソ

ph[1] = (int*)1;
int* tgt1 = ph[1];
}

問題はこちらが使っているのはVC++/CLIで、
なぜか value struct では operator= のオーバーロードが出来ず、(C3194)
マネージ配列に直接入るのは value型だけなのでちょっと詰んでいる。
なお ref struct なら出来るのだが、こちらは逆に初期化部分で記述が増えるので、
それなら諦めようかな、って感じ。

というわけで回避策を思いつく人がいればお願いします。
何で値型で禁止されているか分かる人も居ればよろしく。

2018/01/26(金) 13:51:50.30

イテレータでendの一つ前を表すのはありますか。
endからの引き算必須ですか。

2018/01/26(金) 13:58:16.53

&back()

2018/01/26(金) 14:00:31.27

>>33
用途に合うかどうか分からないけど
rbegin, crbegin

33 (ﾜｯﾁｮｲ ae81-MBfL) · 2018/01/26(金) 14:14:09.94

サンクスです。できました。

2018/01/27(土) 07:12:46.54

rbeginはちょっとトリッキーな実装になってることがあるから注意

2018/01/27(土) 11:46:50.10

実装に依存しないような仕様に沿った使い方をすればいいんでないの？
仕様に合致していない実装ならどうしようもないが。

2018/01/27(土) 19:12:13.06

SHA256のハッシュをkeyにしたmapを高速で扱いたいんだが、
keyのoperator <,>それぞれでmemcmpしてて、多分このせいで性能悪くなってる

なんか良い解決策ってないですかね？
Linuxのrbtreeと比較すると100万件あたり150msec程度差がついてました

2018/01/27(土) 19:13:43.71

simd

2018/01/27(土) 19:44:42.49

unordered_mapにsha256の関数渡せばええやん