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の関数渡せばええやん

2018/01/27(土) 20:08:58.78

fpga

2018/01/27(土) 22:07:02.09

mapじゃなくてハッシュを実装しろとしか

2018/01/27(土) 22:15:03.18

>>40
便利そうだと思ったけど、データ構造的にアライメント揃えられないから使えなさそう

>>41
ソート済みデータを扱いたいパターンもあるので使えないです

コード的にさっくり改善する方法がなさそうなので
map諦めてそこだけ完全自作することにしました
レスしてくれた方々サンクスです

2018/01/27(土) 22:53:57.64

Compareの自作で何がいけなかったのかわからないけど解決おめ

2018/01/27(土) 23:05:46.83

赤黒木ってスマートポインタを使って実装できますか？
親を弱参照で書いたらわけわかめに

2018/01/28(日) 01:55:54.91

ハッシュをソートかあ

2018/01/28(日) 03:22:06.75

コピーしたくないオブジェクトへのポインタ（ていうか全体をシリアライズするの可能性も考えたらindexがﾏｼﾞお勧め）の配列おソートすれば良い
そういった実装の詳細はクラスの中に隠すことができる　何のためにC++を使っているのやヽ(｀Д´)ﾉ！！！１１！１

2018/01/28(日) 08:17:39.92

>>47
なんかモヤモヤするなそれｗ

2018/01/28(日) 11:41:38.50

>>39
hashは値に対してユニークじゃないけどいいの？

**デフォルトの名無しさん** · 2018/01/28(日) 14:41:11.23

そりゃハッシュ衝突用のフィールドくらい作ってるだろうよ
質問にないことは心配しなくていいよ

2018/01/28(日) 15:09:59.60

心配してるんじゃなくてバカにしてるんだよw

2018/01/28(日) 15:44:58.16

バカにしようとして失敗してるとしか見えないけど w

2018/01/28(日) 20:33:36.08

Impliment.h

class Impliment
{
public: base;
};

Interface.h

class Interface
{

2018/01/28(日) 20:42:03.84

すいません。途中で書き込んでしまいました。

以下のようなクラスを作ったのですが、
derivedがImp::baseを継承しているため、
インクルードの順番が固定されてしまいます。（Impliment.hが先でないといけない）

こういったクラスは使う人から見て嫌がられるでしょうか。
ご意見をいただけるとありがたいです。

Impliment.h

class Impliment
{
public:
class base {}
};

Interface.h

template<class Imp>
class Interface
{
private:
class derived : public Imp::base {}
}

2018/01/28(日) 20:56:07.47

>>55
「ＸＸの実装とインターフェイスが分かれている」ということをユーザが意識しないといけないのは抽象化の不足だと思う。
分離した形のデザインで開発するのはかまわないけど、ユーザに対してはなるべく隠すのが望ましい。

#include<Implement.h>
#include<Interface.h>

と書いたヘッダファイルを用意しておく程度のことでもだいぶんマシになる。
(インクルードガードはしておくこと)

2018/01/29(月) 02:50:08.46

>>55
普通は interface.h の冒頭で implement.h をインクルードしておく

2018/01/29(月) 05:39:18.37

>>55
このコードだけならインクルード順が逆でも問題ない。

2018/01/30(火) 20:17:26.27

レスありがとうございます。

>>56
Implimentは複数あって、ユーザーが選ぶことができる
というのを想像して作っていました。

>>57
template化する前はそこでインクルードしていました。

>>58
たしかに、このコードだけでは大丈夫ですね。
正確にはこのコードだけではないので、他に原因があるのかもしれません。
ご指摘ありがとうございます。

2018/01/30(火) 21:08:08.01

Implement入れ替えさせたいならユーザーに適当な所で
template Interface<MyImplement>;
って書かせりゃいいだけじゃないの？

2018/01/30(火) 21:19:19.29

typename imp::base

2018/02/04(日) 11:20:04.76

質問ですが
「このクラスはバイト列としてコピーできる」ということを明らかにするために
明示的にコピーコンストラクタを書くとして、
どう書けば処理系に依存することなくデフォルトのコピーコンストラクタ以上の性能になることを保証できますか
（もしくは、「このクラスはバイト列としてコピーできる」ということを明示する構文はありますか）

2018/02/04(日) 11:26:54.06

>>62
MyClass(const MyClass&) = default;

2018/02/04(日) 11:36:31.71

デフォルトのコピーコンストラクタはメンバのコピーコンストラクタを起動するので、
そのクラス (に属するオブジェクト) 全体がバイト列としてコピーするわけではない。

trivially copyable class の要件を満たすように書けばバイト列としてコピー可能と保証される。
コンストラクタの書き方だけでは保証できない。

2018/02/04(日) 13:04:56.23

memcpyするコピコンをユーザー定義すればええやん

2018/02/04(日) 13:46:35.82

>>63
なるほど「= default;」のありがたみがわかりた

>>64
なるほどそれだと安全性の点でｲﾏｲﾁ…
バイト列としてそのままリモートPCに送ったりするクラスに誰かが
バイト列としてのコピーが可能でないコードを追加したとしても
コンパイラで検出する術が無いっぽいように読める

2018/02/04(日) 13:47:37.01

訂正
誤：バイト列としてのコピーが可能でないコード
正：バイト列としてのコピーを不可能にするコード

2018/02/04(日) 13:47:46.54

>>62
std::is_trivially_copyable<T>がtrueになるように書いて
https://cpprefjp.github.io/reference/type_traits/is_trivially_copyable.html
トリビアル型とは何かは検索して

2018/02/04(日) 13:52:58.38

>>66
なおさらtype_traitsで条件に合わなければコンパイルを失敗させればよい

2018/02/04(日) 14:08:05.83

>>69
おk

2018/02/04(日) 16:47:05.72

>>65
まあ書こうと思えば書けないことはないが、
やった結果に整合性がとれるかどうかは別問題なのでな……。

2018/02/04(日) 17:24:06.38

流れをぶった切って質問するんだけど、
配列の一部をとる参照とかって作れない？
実際にはコンパイルが通らないけど、やりたいことはこんな感じ。

int a[3];
int (&b)[2] = static_cast<int (&)[2]>(a);

2018/02/04(日) 18:06:17.19

reinterpret_castすれば？

2018/02/04(日) 18:22:52.47

ポインタにして剥がせばいい

2018/02/04(日) 18:28:31.26

配列型はポインタではないので途中からとかない

2018/02/04(日) 18:55:06.41

一応うまく行ったけど規格で保証された挙動かどうかはよくわからない
https://ideone.com/wVzc6b

2018/02/04(日) 19:14:07.38

でもポインタにしてしまうと困るシチュエーションなんてありうるの？
マクロの中でsizeofしてるとか？

2018/02/04(日) 20:30:26.18

>>71
意味わかんねえ
どーゆーこと？

2018/02/05(月) 23:20:37.74

メンバのコピーコンストラクタを起動すべきところをmemcpy()しかしない手製コピーコンストラクタで済ませようとしたら破滅が訪れる

MyClass(const MyClass&) = default; なら勝手にやってくれるのでその心配が無いので安心

2018/02/05(月) 23:28:20.73

しかしまあ >>68 なんていう便利なモノがあるとは
フラフラこういうスレ読んでるのもためになるなあ

2018/02/06(火) 07:54:17.35

>>79
>>62

2018/02/06(火) 08:05:48.85

>>62
処理系に依存することなく「保証」なんて出来ない
以上

2018/02/06(火) 08:27:38.08

>>63で解決している
もしくは以下への回答も>>69で出ている

2018/02/06(火) 09:14:20.61

バイト列コピーが = default; なわけねーだろアホ

2018/02/06(火) 11:45:28.85

よく読め
バイト列コピーでokの保証は>>69
遅くならないコンストラクタの書き方が>>63

2018/02/06(火) 11:48:04.39

そもそも「どうコンストラクタを書けば」ってのを質問してるんで
バイト列コピーでコンストラクタを書けってのは単に>>65の珍解答に過ぎない

2018/02/06(火) 11:51:41.68

すまんが日本語でたのむ

2018/02/06(火) 11:54:37.03

元の質問>>62は
・処理系に依存せずデフォルトより遅くならないことが保証されているコンストラクタの書き方
もしくは
・バイト列コピーでokと明示する構文

だろ。
前者は>>63
後者は>>68-69

2018/02/06(火) 12:36:57.61

元質問：　デフォルトのコピーコンストラクタ以上の性能
おまえ：　デフォルトより遅くならないこと

よく読めをそのまま返す

2018/02/06(火) 12:57:03.34

以上っていうのは等しいかまたはそれを越えるという意味だぞ

2018/02/06(火) 14:01:35.47

そもそも memcpy は前者の性能保証も後者の仕様の保証もどちらも満たしてない
仕様が保証されてるなら多分性能的に大丈夫だろうという程度

間違いを認めると死ぬ病気なんだろうからもうこれ以上は言わない。

2018/02/06(火) 14:38:54.29

バイトコピーでmemcpyより高性能な手段を1つでも例示したらどうなんだ

> 間違いを認めると死ぬ病気なんだろうから

ああ、おまえがか

2018/02/06(火) 18:18:02.35

https://stackoverflow.com/questions/28623895/why-is-memmove-faster-than-memcpy

62 (ﾜｯﾁｮｲ 9fbd-CNA0) · 2018/02/06(火) 22:02:19.27

memcpy()より速いコピー手段Xが仮にあったとして
論理的にmemcpy()で済むケースについてコンパイラが提供する
デフォルトのコピーコンストラクタがコピー手段Xにならない理由がわからん…

個人的には「=default;」と書いたら最高性能なんなら毎回手でmemcpy()とか書きたくないｶﾝｼﾞ

2018/02/06(火) 22:06:49.77

>>94
class A {
public:
A() {}
A(A const&) { std::cout << "aho"; }
};

class B {
public:
A a;
B() = default;
};

int main()
{
B b, c = b; //this will call you.
}