C++相談室 part132

2017/10/10(火) 00:11:34.01

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

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

前スレ
C++相談室 part131
http://mevius.2ch.net/test/read.cgi/tech/1501295308/

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

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

2017/11/18(土) 16:50:13.11

>>757
reinterpret_castでいい予感。

2017/11/18(土) 16:51:55.15

>>755
ところでその検証、何年ぐらい時間かけていい話なの？

2017/11/18(土) 16:53:01.86

>>759
未定義動作でも「いい」と言うなら、そう。

2017/11/18(土) 16:55:15.51

あー検証だからな。すまんかった。

2017/11/18(土) 17:20:21.34

みなさま、レスありがとうございます。

>>757
memcpyでできそうです。ありがとうございます。

int main() {
double f = 0;
for (unsigned long long i = 0; i <= -1; ++i) {
void* fp = static_cast<void*>(&f);
void* ip = static_cast<void*>(&i);
std::memcpy(fp, ip, sizeof(i));

std::cout << f << std::endl;
}
system("pause");
}

>>760
そんなに時間かかるんですかね。。。
１週間ぐらいは覚悟してたんですが。
とりあえず回してみます。

2017/11/18(土) 17:32:14.09

>>763
https://randomascii.wordpress.com/2014/01/27/theres-only-four-billion-floatsso-test-them-all/
> ... you can test every float bit-pattern (all four billion!) in about ninety seconds. ...

32bit が 90 秒ほどで済ませられるそうな。 64bit だと単純計算で・・・ 735439.6... 年ぐらいかな。
１週間で済ませようと思ったら 38347922 並列ぐらいで走らせればよさそう。

検証する計算内容によっても変わるだろうけど、まぁがんばれ。

2017/11/18(土) 17:35:34.11

とりあえず範囲を絞って回してみて、
力任せの方法で受け入れられる処理時間なら単純なプログラムのまま、
時間かかりすぎるようなら先にプログラムを洗練させる、としないと。

2017/11/18(土) 17:56:05.12

>>764
ありがとうございます。
32bitと64bitが桁違いですね

範囲を絞ったり、間隔あけてサンプリングしたりしてみます。

2017/11/18(土) 19:06:18.60

isnan()でnanチェック入れたほうが良さそう

2017/11/18(土) 19:44:12.36

>>761
未定義にはならなくね？ポインタtoポインタだからそのまま、で終わりでは。
なお、Cなら

*(long long*)&f = i; // mov命令でコピー
または
f = *(double*)&i; // fmov命令でコピー

>>766
まず仮数部53bit+指数部の偶奇で54bit分でいい。
非正規化数もいらないだろうから仮数部52bit扱いでもいい。
意味が分からないのなら仕様読め>>758

2017/11/18(土) 20:29:47.22

>>768
type-based aliasing rule (strict aliasing rule) というものがあってな。
（詳しく調べると闇に落ちるから言語オタクでもなければ深堀りはおすすめしない。）

mempcy なら動作が定義されてるかというとそうでもないんで、
明示的に未定義といわれているかどうか（＝最適化で問題を起こしやすいかどうか）の違いしかないんだけど。

2017/11/18(土) 20:40:55.67

std::launder「そろそろ俺の出番だな」

2017/11/18(土) 21:23:52.47

ここまでfrexpとldexpの話なし

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd22-EXIO) · 2017/11/18(土) 21:57:24.41

https://github.com/katahiromz/RisohEditor

せっかくだから、だれかバグ発見・修正してけ。

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd22-EXIO) · 2017/11/18(土) 21:58:52.49

初回の例外というのがよくわからない。。。

2017/11/18(土) 22:06:57.57

なんか古い書き方だから2000年ごろからの年季の入ったソースかと思ったら最近の奴なんだな

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd22-EXIO) · 2017/11/18(土) 22:12:33.66

>>774
古臭い技術専門が時代遅れのために作っているもんだから、古いと言われても仕方ない。
auto、C++11が使えるclang++に移行したい。

2017/11/18(土) 22:42:09.82

>>769
調べたけどこれでいいのか？
https://stackoverflow.com/questions/98650/what-is-the-strict-aliasing-rule

これならreinterpret_cast関係ないじゃん。static_castにしたところで変わらん。
ただそれ以前に該当しないだろ。
「同一のメモリを違う型としてaliasしたときにコンパイラがそれに気づけず最適化で削除してしまう」という問題であり、
今回はそうではない。

> mempcy なら動作が定義されてるかというとそうでもないんで
ほんとか？それじゃmemcpyマトモに使えないじゃん。
void*は++で1増えるって仕様に決まったはずで、、、と思ったがこれがgcc拡張だという話があり、このことを言っているのか？

ならグダグダ言わずにCキャストで書けよもう、としか思わないが。
或いはC++的には許せないのかもしれんが static_cast<double>にしてしまうとかか？

2017/11/18(土) 22:48:23.04

すまんミスった
× static_cast<double>
○ static_cast<double*>

2017/11/18(土) 23:20:13.09

>>776
static_cast じゃコンパイル通らない。

"*(long long*)&f = i" は double 型のオブジェクトに long long 型の参照を通してアクセスしているので
未定義動作になる。結果は「最適化で削除してしまう」に限らず、何でもアリだよ。
これが「「同一のメモリを違う型としてalias」に該当しないという理屈も無いでしょ。

memcpy の結果が定義されてるのは、同じ型のオブジェクト間でのコピーだけだったかと。
違う型の間で memcpy した結果の値が実は定義されてるということなら実に興味深いので
ぜひ規格の該当箇所を示して欲しい。

この場合の C スタイルキャストの動作は reinterpret_cast に丸投げされるだけなので話は変わらないよ。

2017/11/18(土) 23:37:48.32

ここまでnextafter/nexttowardが出てきていない

2017/11/18(土) 23:38:32.35

>>778
> "*(long long*)&f = i" は double 型のオブジェクトに long long 型の参照を通してアクセスしているので
してないぞ。
それは「fのアドレスを(long long*)にキャスト（この時点でlong long*型)したアドレスに対しiを書き込め」
であって、つまり long long に long long を書いている。だからmovが出る。
逆に f = *(double*)&i; は double に double を書くから fmov が出る。
その後の最適化で変更されるのはまた別の話。

> static_cast じゃコンパイル通らない。
だったら最初から>>759の言うとおり、reinterpret_castでいいだろ。

> 違う型の間で memcpy した結果の値が実は定義されてる
void* と void* なんだから同じ型だろ。何言ってんだ？

お前、基本的に理解がずれてね？

2017/11/18(土) 23:47:06.34

>>780
なるほど、オブジェクトの型と式の型との区別がついてないんだね。
そこの理解無しで aliasing rule に関する話は無理だから、
C++ の規格を読み直すなりして区別が付くようになってからの出直しをおすすめする。

2017/11/18(土) 23:50:31.47

>>781
俺には君が全く理解出来てないように見えるけどね。
まあ平行線だろうし、終わりでいいけど。

2017/11/19(日) 00:03:31.90

>>782
そうなると GCC も「全く理解出来てない」ことになるねぇ。
https://wandbox.org/permlink/WMFUTpXAgs2oZuos
> prog.cc:5:17: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
> *(long long*)&f = i;
> ^
> prog.cc:6:18: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
> f = *(double*)&i;
> ^

2017/11/19(日) 00:12:55.40

>>782
それ以上恥かきたくなかったらこれ読んでくるといいよ
http://blog-ja.intransient.info/2011/05/c-13.html

2017/11/19(日) 00:41:57.82

まあ未定義な動作がどこまで行っても未定義な動作であって（教条主義的には）悪なのは確かだが
>>784のリンク先のを読むと
>ストアによってPの値が変わる可能性を考慮しなくてはいけないからだ。
という理由で最適化できないケースがあるから考慮する代りに未定義動作ということにしますた！
というだけで、ストアによってPの値が変わらないなら特に問題を生じないように思える…

で、ストアによってPの値が変わるケースというのは
int main() {
P = (float*)&P; // このキャストによって zero_array の中で TBAA 違反となる
zero_array();
}
みたいな変態的なケースしかなさげ；

2017/11/19(日) 00:54:18.30

>>784
答え書いてんじゃねーかよ。

> この種の未定義な振る舞いは、-fno-strict-aliasing フラグを指定することで無効にすることができ
つまり指定すれば万事解決だ。
ただその前にwarning出てても動作するとは思うが。

> この種の型の乱用はあまり一般的ではないので、標準委員会は、"妥当な" 型のキャストによる予期しない結果と引き換えに、大幅なパフォーマンス向上を選んだ。
これっていつから？LLVMに乗せた頃からっぽいが、、、日付や元URL見るかぎりC++11からか？
あとこれって、Cもか？
(Cでは俺が書いたようなキャストは常用されているから）
知っている人がいたらよろしく。

2017/11/19(日) 01:21:45.70

つかmemset(buf, ch, nのbufって__restrictじゃなかったのか…
今知った……

2017/11/19(日) 01:24:03.10

C89からずーっとそうだよ
お前が書いてるコードが動いてるのは、コンパイラがそうしないという保証を独自に与えているか（-fno-strict-aliasingはその一例）
さもなくばたまたま動いてるだけ

2017/11/19(日) 01:33:36.82

>>786
広く知れ渡ったのは gcc 2.95 で実際にそのルールに基づく最適化が行われるようになってからかな。
https://www.gnu.org/software/gcc/gcc-2.95/features.html
> - Type based alias analysis is enabled by default. ...
そこから数えてももう 20 年近く経つわけだが。

知らずにそんなキャスト常用してるなら是非悔い改めてくれ。

2017/11/19(日) 01:35:13.22

（ま、__restrictな形でしかポインタしか使わない漏れには関係ないし…

2017/11/19(日) 01:37:52.26

ちなみに-fno-strict-aliasing付けるとこんな基本的な最適化さえ出来なくなって
パフォーマンスが激悪化する可能性があるからな
それを完全に理解した上で万事解決だと言ってるならそれでもいいけどさ

int foo(double* pd){
　int k = 42;
　*pd = 666;
　return k * 2;
}

-fno-strict-aliasingを付けた場合、戻り値を"84"に最適化することは出来ない
なぜならpdのアドレスが&kを指してるかもしれないから
(strict aliasing ruleが効いてればdouble*がintを指してたら未定義動作なのでケアする必要がなく最適化できる)

2017/11/19(日) 01:42:54.83

>>791
引数で受け取った（有効な）ポインタが関数内のローカル変数を指すことは不可能だから、その例は最適化できるよ。

2017/11/19(日) 02:15:02.16

有効なポインタならね
デタラメなポインタがたまたま&kを指してるかもしれない
普通はそんなのは未定義動作だからケアしないんだけどそれをケアしろって言うのが-fno-strict-aliasing

2017/11/19(日) 02:22:43.60

>>789
> mempcy なら動作が定義されてるかというとそうでもないんで (>>769)
これは間違いだろ。784内見る限り、
> Cは、このような型変換をmemcpyを使って実現することを要求している。
なら、memcpy使えば正しい結果が得られるはずだし、そうじゃないとコンパイラのバグになる。
つまり、>>763のコードは正しく動くはず、と読めるが。

ちなみに>>783のページで色々試してみた。(もし編集が残っているようならすまん)
全てgcc 7.2.0 で、結果は以下。
・CはC11/C11(GNU)の両方でwarinigも何もでない。
・C++はこの中の一番古いC++03/C++03(GNU)の両方でwarinigは出る。
ということはかなり昔からC++ではそうだった、ということだね。全く知らんかったわ。
ここら辺がCの連中がC++を嫌っているところなのかもしれない。

>>788
おお、サンクス、C++89からか。
俺環はVC++2008だからね。MS側が吸収してくれてるわけか。

>>789
いや俺環では問題ないしな。
つかたぶんこれC++の話で、上記試した限りCなら問題ないんだよ。
ただ俺はbetterCの人だから、まあ微妙なわけだが、、、VC++2017とかに移行するときは気をつけるよ。

さてそのリンク先
https://www.gnu.org/software/gcc/news/alias.html
も読んでみたが、つまり s->x_m[i] は s->a_m と型が違うから上書きしないはず、
だからループ内で毎回 s->a_m を取らずに前回の値をそのまま使っていい、ということらしい。(s->b_mも同様)
ただこれなら
for (unsigned long long i = 0; i <= -1; ++i) *(long long*)&f = i;
は確実に動くけどな。ここで端折られるのはfのアドレス確認 &f 部分だけだから。
ただしstackoverflowの連中は言っていることが少し違うから、もうちょっと確認が必要だが。

2017/11/19(日) 02:26:53.00

>>793
んなこたーない。
https://godbolt.org/g/wDD6Zk

2017/11/19(日) 02:37:45.46

>>791
周回遅れですまんが俺には794に書いたとおり、
・型違いは全てmemcpy使え。
と読める。だから763のコードはOKだと。

>>791-793の内容は理解した。
さて再度だが、やはり以下は動くだろ。

for (unsigned long long i = 0; i <= -1; ++i) *(long long*)&f = i;

ここで問題なのは、「fがiのアドレスをさしてたら未定義動作(&f==&i等)」であって、
i をコピーしてやらない、ではない。
791-793の言い分どおりなら、これはwarningが出てるだけで全く問題なく動くはず。
ただしstackoverflowの連中はちょっと違うことを言っているが。

2017/11/19(日) 02:42:26.05

>>794
C の aliasing rule には memcpy, memmove によって宣言型を持たない（たとえば
malloc で確保した）オブジェクトの型 (effective type) を変更できるという規定がある。
引用された「memcpyを使って実現することを要求している」はこのことだろう。

でも、 C++ にはこれに相当する規定が無い。

2017/11/19(日) 02:53:12.72

>>796
残念、まだ理解できてないよ。

答えは >778 にある。
> "*(long long*)&f = i" は double 型のオブジェクトに long long 型の参照を通してアクセスしているので
> 未定義動作になる。結果は「最適化で削除してしまう」に限らず、何でもアリだよ。

これ以上は規格見てからしゃべってくれ。

2017/11/19(日) 03:03:03.03

てゆーか、見てなかったけど763はfor文回らねーじゃねーかよ！

>>798
ちょうどよかったので今>>795を改造してアセンブラ見てるんだが、、、すまんが今日は寝る。
昼前にはまた書くよ。

2017/11/19(日) 06:07:15.51

未定義動作ﾏｼﾞｺｴｰ；；（>>784のリンク先の次のページ
ttp://blog-ja.intransient.info/2011/05/c-23.html

2017/11/19(日) 06:25:20.22

プロセス屋さんががんばってCPUを3年ごとに倍早くしてくれるのだから
我々ソフト屋は口を開けて待っているだけにして
最適化なんてやめてしまえば良いのに

我々が忙しく働くということは、それだけバグを産むということなのだ…！

2017/11/19(日) 07:18:18.83

>>795
出来ると主張する人に対して
たまたまできない一例を根拠に
出来ないことの立証を主張されても…

2017/11/19(日) 07:18:20.90

CPUだけ速くなってもDRAMの速度が昔のままだ
.7CRなんて法則を持ち出すまでもなく
現実にCPU速度が飽和したと感じたことなどないはずだが

2017/11/19(日) 07:23:52.01

>>795
>>802は夢をみた。忘れて

2017/11/19(日) 08:50:45.23

>>768
読んでも分からないときは？

2017/11/19(日) 10:12:41.15

>>805
ここで実験してみるとか
https://people.rit.edu/meseec/eecc250-winter99/IEEE-754hex32.html

2017/11/19(日) 13:02:38.85

>>795改造は-fno-strict-aliasing有り無しによらず動くコードが出た。詳細は以下。

https://godbolt.org/g/QaSwTn
-O3 -fno-strict-aliasing -std=c++14 -pedantic -Wall -Wextra で mov QWORD PTR [rsp+8], rbx (27,29行目）が出る。
-fno-strict-aliasing を切っても同じ mov 命令が出る。
だからこれはwarningが出ているだけで動くコードが出る。
このときのコードは以下。
void test() {
double f = 0;
for (long long i = 0; i <= 10; ++i) {
*(long long*)&f = i; // (A)
std::cout << f << std::endl; // (B)
}
}

2017/11/19(日) 13:04:16.49

>>798
なお上記のGCC結果、或いは以下GCCのドキュメントは読んだ。
(ついでに後出の仕様書もチラ見したが、やはり今のところ君の理解がずれてるという見解だ。)
https://gcc.gnu.org/onlinedocs/gcc-4.4.3/gcc/Optimize-Options.html#index-fstrict_002daliasing-750
ここでは以下コードがアウトだと言っている。
union a_union {
int i;
double d;
};
int f() {
double d = 3.0; // (C)
return ((union a_union *) &d)->i; // (D)
}
アウトな理由だが、上記と794内URLによると、「『型違いのaliasはない』と仮定して最適化」する為であり、
つまり(C)はd名でdoubleに書き(D)はi名でint読み出しだから(C)と（D)は関係ない、
よって(C)はデッドコードでいきなり（D)の読み出ししてよし、ということらしい。

ただこれだとやはり上記(A)(B)は動く。(A)も(B)もfの読み書きであり、aliasして無いからだ。
この規定は「型違いの『aliasは』ないものとみなす」であり、aliasしてなければ関係ない。
今のところ見る限り、他の例も必ずalias（別名でアクセス)している。

なお正しくはunionを使え、ということらしい。>>763
まあ確かにunionはこれ用ではあるが、単発ならCキャストする奴が多いとは思う。
そもそもunionは撲滅対象だと思っていたのだが、これは意外だ。
(或いは仕様上 char*, unsigned char* については許可《どう見ても妥協だが》しているので、void*ではなくchar*にすればいい)

2017/11/19(日) 13:06:08.29

仕様書は以下でいいか？読み慣れてないからだいぶ推測が入るが、
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf
俺の結論は以下かな。

・gccのは -fstrict-aliasing で、あくまで alias についてだが、仕様書内は alias なんて関係ない。
・fstrict-aliasing 出来る理由が3.10.10によるのなら、reinterpret_castの存在価値はなく、仕様書内に矛盾がある。
・おそらく reinterpret_cast 撲滅で union に書き換えろ、という方向か？
aliasってのは多分折衷案で、union 以外は全部アウトにしたいっぽい。

詳細は以下。

5.2.10 Reinterpret castでは特に妙なところはなし、型キャストは為される。
aliasについては3.10.10だが、reinterpret_castしてれば the dynamic type 扱いでアクセスに問題なし、と見る。
3.10.10.の注 54) The intent of this list is to specify those circumstances in which an object may or may not be aliased.
なんだから、やはりこれは alias されているかどうか？であって、アクセスできるかどうかではない。
ただしここを根拠に undefined behavior だから最適化してよし、としてるのはかなり強引で、
(というかここでalias云々がかなり唐突で、そもそもaliasの話をここではしていない)
(D)がreinterpret_cast扱いだというのなら仕様内に矛盾があることになる。
そしてこの解釈(=reinterpret_castされたものは the dynamic type ではなく undefied behaviorだからどうなってもよし）が通るのなら、
reinterpret_castの存在価値がなくなってしまうし、
aliasとかせこいことを言わず、reinterpret_cast相当のところは全部undefined扱いで削除していいことになる。
というか、多分コンパイラ側はこの主張で、これに対してユーザ側が反対し、
結果、 alias とかいう折衷案でごまかしているように読める。（既に書いたがaliasが唐突過ぎ）
確かに正しくはunionを使うべきであり、この流れだと将来的には reinterpret_cast は廃止で union しろってことになるのか？
しかし逆に言えば、C++89以来これで大して変わらないのなら、早々急に変わることもないか。

2017/11/19(日) 14:06:40.01

>>787
ポインタの引数が１つしかないのに__restrictつける意味ないからでしょ

2017/11/19(日) 14:19:11.46

コンパイラがうまくType-Based Alias Analysis出来るケースをいくら列挙したところで
Type-Based Alias Analysisできないケースが簡単に生じることは否定できない事実じゃんヤバイじゃん？

unionの使用が解決策というのも語弊があって、unionのメンバのアドレスを取ってから関数foo()に渡す手順だと
foo()のコンパイル時には渡ってきた2つのポインタが、型が違うけど（ループ変数などの条件次第で）同じ領域を指す（ことがある）
かどうか（ループを実際に実行してみねば）判断つかないじゃん？→コンパイラは怖くてループをmemcpy()やmemset()に置き換えられない

つまりunionこそ別の翻訳単位に属する関数に下手な渡り方をするとaliasingのすくつと化す気配が微ﾚ存

元を断つにはやっぱID:xhmNfS4m0やGCC様がおっしゃるように、
そもそも型の混同要因（つまりポインタのキャスト）を絶つか、最適化が効いてほしい関数でプログラマが明示的に__restrictするしか、

※ 個人の感想です

2017/11/19(日) 14:25:36.63

>>808
> ただこれだとやはり上記(A)(B)は動く。(A)も(B)もfの読み書きであり、aliasして無いからだ。

どうも "alias" の有無を名前に基づいて考えてるみたいだけど、
C++ （ほか多くのプログラミング言語）の文脈ではソースコード中で使われる実際の名前は関係ないんだよ。
"*(long long*)&f = i;" は "auto p = (long long*)&f; *p = i;" と等価であり、
これらのうち名前をつけた後者だけがエイリアスの問題があるということはなく、
どちらも f が表すオブジェクトに対してエイリアスがある状態と言う。
（最適化器の気持ちになって考えればわかりやすいんじゃないかと思うんだけど・・・。）

3.10.10 の注が "alias" に言及しているのも、このルールが "aliasing rule" と
呼ばれるのもそういうこと。

> なお正しくはunionを使え、ということらしい。>>763
> まあ確かにunionはこれ用ではあるが、単発ならCキャストする奴が多いとは思う。

union で最後に書いたメンバと別のメンバを読み出すのも C++ では未定義動作だよ。
gcc は（ -fstrict-aliasing の説明にもあるとおり）特別ルールを設けてある程度の保証を与えている状態。
https://gcc.gnu.org/bugs/#casting_and_optimization
> To fix the code above, you can use a union instead of a cast (note that this is a GCC extension which might not work with other compilers):

2017/11/19(日) 14:26:49.64

>>809
> ・fstrict-aliasing 出来る理由が3.10.10によるのなら、reinterpret_castの存在価値はなく、仕様書内に矛盾がある。

元の型に戻せば元通り使えることが保証されているので、変更できない既存ライブラリの型に情報を無理やりねじ込んだりするのには使える。
3.10 の例外により unsigned char* などによるオブジェクト表現への直接アクセスにも使える。

> aliasについては3.10.10だが、reinterpret_castしてれば the dynamic type 扱いでアクセスに問題なし、と見る。

まだオブジェクトの型 (dynamic type) と式の型との区別がついてないようだねぇ。

2017/11/19(日) 14:38:42.54

>>810
memset()にわたるbufが__restrictでないポインタでないということは、関数の中で
　memset(p, 0, 1000);
　...
　memset(p, 0, 1000);
と2回呼んだとき、pが非__restrictだったりグローバル変数だったりするとバカ正直に2回memset()されてしまう…

また、memset()は該当しないが
一般論としてポインタの引数が１つしかなくとも大域変数経由で（一見別のエリアを指すように見える）ポインタを受け取るケースがあるので
1引数関数でも__restrictが要るケースがあるんじゃわ；

2017/11/19(日) 14:43:08.58

>>811
808のコードで言うとね、

union a_union {
int i;
double d;
};
int f() {
double d = 3.0; // (C)
return ((union a_union *) &d)->i; // (D)
}

がアウトで、

int f(a_union* u) {
u->d = 3.0; // (E)
return u->i; // (F)
}

にしろってことだよ多分。これは>>812内URL内容とも一致する。

>>812
と、ここまではいいとして、これもGCC拡張であり、
> union で最後に書いたメンバと別のメンバを読み出すのも C++ では未定義動作だよ。
これはマジなの？C++のunionのところを読めばいいのか？

> 最適化器の気持ちになって考えればわかりやすいんじゃないかと思うんだけど・・・
これの可能性も考えたんだが、これまで全ての例で必ず別名をつけられてる。
LLVMはあまり知らないが、LLVMにおいてはレジスタへの再代入は禁止のはずだから、
同じレジスタがずっと使われてて最適化器からも「同じだ」と見える可能性もあるよ。

2017/11/19(日) 14:46:54.14

ごめ>>814の前半は思い過ごしかorz
別にmemset()側に__restrictは要りませんな…

2017/11/19(日) 14:52:43.00

>>813
3.10.10.4 a type that is the signed or unsigned type corresponding to the dynamic type of the object,
って言ってんだから基礎型も the dynamic type に含まれてると思うぞ。

> 変更できない既存ライブラリの型に情報を無理やりねじ込んだりするのには使える。
使えない。
reinterpret_castの結果がlvalueとして正当ではない、だからundefinedで何やってもおk、
というのが最適化していい根拠なんだろ。だったらreinterpret_castしたその値を使う時点で駄目だろ。
lvalueとして正当に使えると言うのなら、undefinedじゃないんだから最適化で削除しては駄目だ。

ただまあ、ここら辺を俺と君でやりあっても意味が無い。
おそらく20年前にガチで同じことが彼らによって既に為されているはず。
俺がコンパイラを作るわけでも無し、俺は現状確認だけでいいよ。

2017/11/19(日) 14:57:33.47

>>814>>816
＞一般論としてポインタの引数が１つしかなくとも大域変数経由で
あ、そういうことか・・・
まぁmemset使ってそういう症状出るとしたら、呼び出し側のpでつければいいよね

自分は__restrictそんなに使い倒してないけど、C++の標準に入らないのかな

2017/11/19(日) 15:03:35.17

>>817
これだけ言われてまだ dynamic type が何なのか読んでないとしか思えない発言が来るか。
https://timsong-cpp.github.io/cppwp/n4659/intro.defs#defns.dynamic.type

> reinterpret_castの結果がlvalueとして正当ではない、だからundefinedで何やってもおk、
> というのが最適化していい根拠なんだろ。だったらreinterpret_castしたその値を使う時点で駄目だろ。

ポインタの reinterpret_cast で型違いの結果を得ることは未定義動作にならないし、
それに * を適用して lvalue を得ることも未定義動作にはならない。
得られた lvalue を通したアクセスが aliasing rule に基づいて未定義動作となる可能性がある。

2017/11/19(日) 15:04:02.65

>reinterpret_castの結果がlvalueとして正当ではない
えっ合法なんじゃ…
　int x = 10;
　char* p = reinterpret_cast<char*>(&x);
　*p = 2; // *pがlvalueであるところの式
　x = (int)*p;　 // 元の型へのキャストバック
　printf("x=%d\n", x); // 2

多分最適化されると
　printf("x=%d\n", 2);
になる

2017/11/19(日) 15:19:05.40

>>812
> union で最後に書いたメンバと別のメンバを読み出すのも C++ では未定義動作だよ。
一応unionのところ(9.5)読んだ。これは書いてなかった。
ただしGCCが「独自拡張だ」って言ってんだからどこかにはあるのだとは思うが。
章番号分かればよろしく。まさか、書いて無いから未定義って奴か？

なお9.5.5ではanonymous union ってのが定義されてて、どうもこれでやれってことっぽい。
例は以下。

void f() {
union { int a; const char* p; };
a = 1;
p = "Jennifer";
}

2017/11/19(日) 15:22:01.05

dynamic_typeはdynamic_cast<>とかtypeidの実装がvtableを悪用した黒魔術なので使わなーい

それはそうとして、Type-Based Alias Analysisの障害となるaliasingだけことさら問題視するLLVMの人らのスタンスはフェアではないｷﾓｽ
同じ型でもaliasingは起こそうと思えばいくらでも起こせるし、コンパイラはプログラマーが意図的にaliasingさせるケースが有り得るのではと
猜疑心にとらわれて十分な最適化ができないのは同じ

やっぱC++は関数型プログラミング言語にシフトすべき頃合い

2017/11/19(日) 15:27:33.98

>>819
3.10.10には the dynamic type と cv-qualified version of the dynamic type しかないのだが、
では double や long long は何型なのだ？

> 得られた lvalue を通したアクセスが aliasing rule に基づいて未定義動作となる可能性がある。
ではその aliasing rule を読もう。何章だ？
なんとなく aliasing rule はコンパイラ側の仕様で、C++の仕様では無いと思うのだが。

2017/11/19(日) 15:35:56.40

>>823
なんでせっかくリンク貼られた定義を無視するの？（・・・英語まともに読めないならそう言ってね。）
dynamic type は式を評価した結果の属性であって型の分類ではない。

aliasing rule は basic.lval にあるルール "If a program attempts to access ... the behavior is undefined" を指す。
https://timsong-cpp.github.io/cppwp/n4659/basic.lval#8

2017/11/19(日) 15:36:33.89

規格キチガイとの会話は不毛
ツルッツルピカピカ

2017/11/19(日) 15:39:23.48

>>822
違うぞ。
794内リンク読む限り、確かにこの最適化はフェアだし、使われていい。
というか、それ以前はポインタが一つでもあったら全く最適化が出来なくなっており、
確かにそれは問題視されてた。
だから標準化委員会がそっちを選んだ、というのは分かる話だ。
違う型でエイリアスすることはほぼないし。

問題は意図的にやりたいことが偶にあって、そのときにどう回避するかだよ。
763がこれに該当する。

2017/11/19(日) 15:51:01.10

>>826
現行の規格で保証される範囲でまともな方法を見出そうとしてるなら、苦労に見合う実りは得られないからやめとけと言っておく。
標準化委員会のおおかたもそんな認識だから bit_cast なんていう提案が好意的に進められている。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0476r1.html

2017/11/19(日) 15:53:50.85

>>824
では最初から分かるようにそう言え。

こちらは仕様書を読むのが仕事ではないので、そもそも用語も知らない。見て分からなければそれまでの話だ。
つか、lvalue, rvalue もひどいが、 xvalue とかもでてきて、いよいよC++はどうしようもなくなりつつあるなと実感したよ。
Linusが嫌うわけだよこれは。

ただまあこれは本題でもない。 aliasing rule の確認の方が重要だ。
してそのリンク先、3.10.10と同じだ。

> 得られた lvalue を通したアクセスが aliasing rule に基づいて未定義動作となる可能性がある。(>>819)
これはどこからそう取れるんだ？
reinterpret_castをした結果が正当なlvalueなら、それをデリファレンスした結果も正当なlvalueだろ。
この章にはどこにも”aliasしてる場合”なんて記述はない。
だらからここを根拠にするのがそもそもおかしいんだよ。

君が期待することがここに書いてあるとしたら、例えば以下になるべきなんだよ。

the dynamic type of the object IF THE OBJET IS NOT ALIASED,

とかね。でも実際はそうじゃない。

2017/11/19(日) 16:10:52.86

>>827
つか、完全に暴走してるなこれは。

これならmemcpyと同じだし、
わざわざ別に作らずともmemcpyを正式に認めてCと同じ並びにしたほうがいい。
それ以前に reinterpret_cast が使われている関数内は自動的に -fno-strict-aliasing すればいいだけなんだが。
（関数単位でこの最適化を切る。ほぼ全てこれでいけるはず）

ただまあ、これが真面目に議論されているのなら、仕様書の文面や俺の感想はともかく、
君の言う通り、今のC++の仕様では対処する方法がない、ということなのだろうね。

2017/11/19(日) 16:11:41.87

>>828
"If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undefined"
これが lvalue （それ自体は未定義ではない）を通した「アクセス」を未定義とするルールとして読めないのだとしたら、もうどう説明しても無理だろう。
用語を知らないといいながら共通の定義を求めるのではなく開き直って勝手な解釈に基づく話を進められるようではまともな会話にもならない。
説明は諦める。

規格や先人の解説を読みなおすなりして誤りに気づいてもらえれば幸いだ。
https://www.google.com/search?q=aliasing+rule

2017/11/19(日) 16:30:16.51

>>830
ちげーよ。
俺は、reinterpret_castの結果が正当なlvalueなら、それはド頭の
the dynamic type of the object
に該当するから、
*(long long*)&f = i
はありだろ、と読んでるんだよ。そこは君も同じだろ。

> ポインタの reinterpret_cast で型違いの結果を得ることは未定義動作にならないし (>>819)
つまり (long long*)&f で long long* 型になるのはおｋ ←君の見解ね、俺も同意だが。

> それに * を適用して lvalue を得ることも未定義動作にはならない。
得られた lvalue を通したアクセスが aliasing rule に基づいて未定義動 (>>819)
つまり、*(long long*)&f もおk ←これも君の見解ね、俺も同意で。

> 得られた lvalue を通したアクセスが aliasing rule に基づいて未定義動作となる可能性がある
ここが違う。
3.10.10には alias が云々って何も書いてないだろ。
しかも *(long long*)&f = i; は両方とも long long なんだから、「型違い」のaliasではないんだよ。
だからGCC等の -fstrict-aliasing には該当しない。

というのが文面からとれる意味だ。あくまで「文面」な。
ただまあ、実際にはそうじゃないんだろ。

2017/11/19(日) 16:33:08.86

ああすまん、ちょっと慌ててて余分なコピペされてるわ。
上記1回目の「得られた lvalue を通したアクセスが…」は余分で。

2017/11/19(日) 16:34:35.29

>>830
> 俺は、reinterpret_castの結果が正当なlvalueなら、それはド頭の
> the dynamic type of the object
> に該当するから、
> *(long long*)&f = i
> はありだろ、と読んでるんだよ。そこは君も同じだろ。

違うねぇ。
オブジェクトの型 dynamic type は式の型とは違うし、式の型の影響を受けるものじゃないんだよ。
何度も区別しろと言ったつもりだったんだけど。

2017/11/19(日) 16:35:57.16

ごめん、アンカーミスった。 >833 は >831 宛てね。

2017/11/19(日) 16:43:31.03

>>825
確かに自分に中身のないやつほどルールブックを神格化するよな
自分なりにどう思うなんて怖くて言えないから
で、そういうお前さんは何か内容のある発言ができるのかね？

2017/11/19(日) 16:46:31.93

> *(long long*)&f で long long* 型になるのはおｋ

んなこたーない
doubleオブジェクトの領域にlong longでアクセスすることが未定義動作

2017/11/19(日) 17:22:20.65

double f = 0;
と変数fを構築した時点で、「値0.0のdoubleオブジェクト」が作られてメモリに置かれるんだよ(規格で言うstored valueな)
それはスタック回収やdeleteで破壊されるまでずーーっとdoubleのままで、変わることはないの
外側でポインタや参照をどれだけいじくり回したって決して変わらないの

家の横に「←ここは馬小屋です」って看板を立てたって、その家は家のままだし、勝手に馬を入れて飼うのは未定義動作なんだよ
そろそろ理解したらどうなの

2017/11/19(日) 17:56:59.79

>>835
内容ある発言と言われても別にこんなのは規格をひっくり返して議論するようなことでないし
たぶん俺なら（little endianだとして）
union Double {
double v;
struct {
uint64_t f:52; // fraction
uint64_t e:11; // exponent
uint64_t s:1; // sign
};
};
とかにするかな、それで何の問題も起こらない

2017/11/19(日) 18:00:09.08

>>837
多分それが違うぞ。それはどこに書いてある？

少なくとも多くのCプログラマはそう思って無い。だから平気でキャストする。
そして830内ULRも読んだが、これも明示的なエイリアスがあるケースだ。
お前らが過度にびびって拡大解釈してるだけだろ。

2017/11/19(日) 18:11:47.43

あー、こいつcast-as-lvalueに完全に洗脳されている手合いかｗ

2017/11/19(日) 18:14:47.74

>>839
https://timsong-cpp.github.io/cppwp/n4659/intro.object#1
> ... The properties of an object are determined when the object is created. ... An object has a type. ...

今度からは少なくとも自分でどこをどう探したかぐらい示そうな。

2017/11/19(日) 18:31:26.29

>>841
嘘つけ。キャストした場合についてはどこにも書いてない。
型が普遍なんてのは、君が勝手に思い込んでいるだけだ。
というか、いわゆる「強い型」ってのはそうらしいが、C++はそうじゃないだろ。

ちなみに俺も反論を用意してたところだ。
https://godbolt.org/g/viYhGj

中身は795の場所で、ついでだから f = *(double*)&i; を試した。
予想通りこちらはfmov(movsd)が出た。(最適化は切ってある）
つまり、俺が768で言ったように、

*(long long*)&f = i; // mov命令でコピー
または
f = *(double*)&i; // fmov命令でコピー

になるんだよ。少なくともgccはキャストされればその型だと認識している。
君はこれを矛盾無く説明出来ないだろ。

2017/11/19(日) 18:51:00.89

>キャストした場合についてはどこにも書いてない

はて、N4700の6.10/p8ほぼそのままの文面が少し上に貼り付けてあったような…

>>821
N4700 3.9, 4.5/p1, 6.8全般, 6.10/p8, 12.3/p1, 12.3/p(5.3), その他「launder」が登場する記述全般

2017/11/19(日) 18:52:07.63

正しいそうなコードが吐かれたことは未定義動作でないという証拠には全くならない
なぜなら未定義動作というのは
コンパイル時のエラー、実行時のエラー（または例外）、一見正常っぽく気体通り動く、その他、
というあらゆる事象を包含し得るので、、、

もちろんコンパイラの変更で（ことによったらコンパイル条件の変更だけでも）
ある日突然狂ったコードが吐かれる危険性があるが
そうなっても未定義動作をプログラムした人の責任
よって現時点で正しいげなコードが吐かれることをいかに力説しても無駄で、
規格の矛盾の指摘にはつながらない

2017/11/19(日) 18:53:33.74

>>842
オブジェクトの型に関与しない操作についていちいち記述があるわけないだろ。
まさか「～によりオブジェクトの方は変わらない」とかの記述が全演算子＆標準関数その他諸々について必要だ
なんて言うわけじゃないよね？

未定義動作の結果はなんでもアリだと言っただろう。
その結果（想定の命令コードが生成されたこと）が未定義動作の結果のひとつだとして、何の矛盾も無い。

2017/11/19(日) 19:03:59.08

inline const self_type *const_this()
{
return this;
}
template <typename T_TYPE>
inline T_TYPE *drop_const(const T_TYPE *obj)
{
return const_cast<T_TYPE *>(obj);
}

2017/11/19(日) 19:04:38.54

ソースが仕様、ソース読めってやつか。

2017/11/19(日) 19:25:00.73

そう言って居直るやつは問題だが
ソースを読まない言い訳にするやつもダメ
腐敗は両岸から起きうることだ

2017/11/19(日) 19:53:33.03

>>844-845
うむ。それは一理ある。

>>845
では逆から行こう。reiniterpret_castのど頭、
> 5.2.10 Reinterpret cast
> 1. The result of the expression reinterpret_cast<T>(v) is the result of converting the expression v to type T.
vをTに型変換したのが結果だとそのまま書いてある。
これはどう解釈すれば、「型はどうやっても変更できない」と取れるのだ？
さすがに無理だろ。

> 7. An object pointer can be explicitly converted to an object pointer of a different type.
これも型を変更できると読めるが。そして再び1に戻ると、

> 1. ---- If T is an lvalue reference type or an rvalue reference to function type, the result is an lvalue;
つまり当然有効なlvalueであり、デリファレンスも可能だ。
だからキャストを反映してmovなりfmovが出るのだ。
違うか？
君が言うようにメモリ上の型が普遍なら、どうやっても i には fmov が出ては駄目だろ。
（と思ったが、君は837ではないのか、、、)

2017/11/19(日) 20:02:38.24

>>849
If T is an lvalue reference typeという但し書きがついているよな
(double&)ならlvalueだが(double)は違う

2017/11/19(日) 20:09:33.36

>>849
> これはどう解釈すれば、「型はどうやっても変更できない」と取れるのだ？

式の型 (static type) は変わるが、オブジェクトの型 (dynamic type) は変わらない。

> 君が言うようにメモリ上の型が普遍なら、どうやっても i には fmov が出ては駄目だろ。

未定義動作ならなんでもアリだと言った。

2017/11/19(日) 20:15:36.23

>>851
それで突っぱねるのなら平行線だね。
俺は仕様書に詳しいわけでは無いから動作から説明するしかない。
君は仕様書には詳しいようだが、キャストした場合にも型が変更されないという記述を出して来れない。
ま、デッドロックだ。

とはいえ状況は色々分かったよ。ありがとう。

2017/11/19(日) 20:42:27.06

>つまり当然有効なlvalueであり、デリファレンスも可能だ。

仕様を引用して説明されてもこのとんちんかんな発言を繰り返すあたり、
知らないから間違えているのではなくオツムが悪いので必然的に無知になったと言うことに>>851は気付くべき

2017/11/19(日) 20:47:51.98

>>852
> 俺は仕様書に詳しいわけでは無いから動作から説明するしかない。

なら↓お前の理解に基づいてこの動作を説明できるか試してみるといいかもしれない。
https://wandbox.org/permlink/2aKzO4VN3KRDB6Gu

> 君は仕様書には詳しいようだが、キャストした場合にも型が変更されないという記述を出して来れない。

式の型 (static type) とオブジェクトの型 (dynamic type) は別物だという客観的な
前提 [intro.defs] を素直に読みさえすれば何度も見えてるはずなんだけどな。

2017/11/19(日) 20:54:00.37

こいつわかってて引っ掻き回してるだけのような気がするわ
そうじゃなかったら馬鹿すぎる

2017/11/19(日) 21:10:07.51

ある型の変数を入力として、別の型にキャストされた値を返すのはそりゃできるだろう
元の変数の型を変えることはそりゃ無理だろう

2017/11/19(日) 21:20:19.91

>>854
それは何も不思議じゃ無いと思うが。
例の最適化もされてるし。

どこが俺の理解と矛盾してるつもりなんだ？

2017/11/19(日) 21:40:24.30

>>857
お前の中でどういう理解になっているかは把握できていない。

その答えからすると、
"*(long long*)&f = i;" なら未定義動作にならないけど "auto p = (long long*)&f; *p = i;" なら未定義動作になる、
という理解なのかな。まぁそんなことは無いんだけどさ。