C++相談室 part149

**デフォルトの名無しさん** · 2020/02/18(火) 06:19:41.54

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

前スレ
C++相談室 part148
https://mevius.5ch.net/test/read.cgi/tech/1580471646/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1556142878/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

**デフォルトの名無しさん** · 2020/02/29(土) 16:37:43.01

要はlistとvectorの違いは何で、なぜ必要かという文脈でいいのかな
listはfor文にi++入れないための単なる糖衣構文だと思うが
基本的に自分は糖衣構文は必要ない派です

**デフォルトの名無しさん** · 2020/02/29(土) 16:37:52.88

リンクリスト万能君も老害リストに追加だね
キャッシュヒット率低いし、64bitポインタの無駄もでかいし
メモリ空間異なるところもっていくときに全部作り直しだし
昨今はむしろ使えないデータ構造扱いされること多いから
c/c++を高速化のために使ってるならなおさら

**デフォルトの名無しさん** · 2020/02/29(土) 16:38:02.22

長文書いてる人は全員釣り師。

**デフォルトの名無しさん** · 2020/02/29(土) 16:40:06.91

>>338
測定すればすぐわかる事なのにね。
そもそも教科書は挿入に焦点を当ててるけど、検索のほうがよほど問題。
algorithmと極端に相性が悪い。
listを使う理由はイテレータの安定性のみ。

**デフォルトの名無しさん** · 2020/02/29(土) 16:45:07.46

>>340
測定だけでは見落とすことが有る。
測定しただけで std::vector の方が速いと思っている人は、数学的想像力が足りてない。

**デフォルトの名無しさん** · 2020/02/29(土) 16:47:16.55

>>341
だってキミ嘘しか書いてないやん。
最初から全部嘘だし。
どう見たって釣り師。

**デフォルトの名無しさん** · 2020/02/29(土) 16:48:55.39

>>342
恐らくIQが高いので一般プログラマはついてこれない。

**デフォルトの名無しさん** · 2020/02/29(土) 16:49:11.83

はいもう釣り堀は終わり。

**デフォルトの名無しさん** · 2020/02/29(土) 16:55:50.08

高IQの人と一般の人とは話が通じ合わない。

**デフォルトの名無しさん** · 2020/02/29(土) 17:09:06.31

はいこのおじいちゃんの毎度の捨て台詞いただきました

**デフォルトの名無しさん** · 2020/02/29(土) 17:16:14.77

> algorithmと極端に相性が悪い。
> listを使う理由はイテレータの安定性のみ。
とか書くような奴もどうかと思うわ

**デフォルトの名無しさん** · 2020/02/29(土) 18:09:51.88

嘘つくやつって特有の変なプライド持ってるよな。

**デフォルトの名無しさん** · 2020/02/29(土) 19:24:46.81

話者に対してレベルが低過ぎる人には話が嘘か間違いにしか聞こえない。

**デフォルトの名無しさん** · 2020/02/29(土) 19:55:24.32

嘘つきがレベル高いってのは
赤軍派の暴力事件が相次いでいた頃の
共産主義＝インテリのステータスだった時代の
今となってはもうみんな気付いている茶番とインテリぶったやつらが
真っ赤な最高学府で安々と洗脳されたバカばっかりだったという
お笑いぐさのやつだね

**デフォルトの名無しさん** · 2020/02/29(土) 19:57:19.47

動的配列より全面的に優れているって何かのギャグなの？w

**デフォルトの名無しさん** · 2020/02/29(土) 21:20:16.71

>>336
Cに慣れた人間がリンクリストを好む傾向があるのは、
動的配列が一段抽象化層を設けないと扱いづらいのに対してリンクリストはCの自然な構文で生のままで扱いやすいからだよ
君自身も君が馬鹿にしている「癖」に縛られているんだ

◆QZaw55cn4c · 2020/02/29(土) 21:49:19.01

>>349
仮に IQ が存在するとして、 IQ に差があるのならば、IQの低い受け手はIQの高い話し手の発する全情報を解釈するのに困難を感じることは確かにあり得るとは思いますが、
「嘘か間違いにしか聞こえない」というのは、IQの差だけでは説明できないと思います
IQの低い私の体験としては「わからない」とはいつでもよく感じていたりするのですが、それでも「嘘だ」「間違っている」とは普通は考えませんね

**デフォルトの名無しさん** · 2020/02/29(土) 22:20:21.84

リンクリストって今時のCPUにとって非常に性能上扱いづらいものだからねぇ

順繰りにたどっていく場合に先読みがしづらい
実体を指すポインタの配列なら2つ先、3つ先のアドレスまでキャッシュに載っているから、プリフェッチが効いて必要になる頃にはキャッシュにロードされてる感じになる

**デフォルトの名無しさん** · 2020/02/29(土) 22:36:08.55

>>345
ここにはお前と話が通じない一般人しかいないから、お前と話ができる人がいるどこかよそに行った方がお互い生産的だと思うぞw

**デフォルトの名無しさん** · 2020/02/29(土) 22:37:49.26

>>354
デタラメ書かない

**デフォルトの名無しさん** · 2020/02/29(土) 22:40:10.33

>>356
デタラメではないでしょ
キャッシュヒット率意識するのは大事

**デフォルトの名無しさん** · 2020/02/29(土) 22:51:13.30

プリフェッチとか色々ごっちゃになってる
断片的な知識で知ったかしようとして失敗してるパターン

**デフォルトの名無しさん** · 2020/02/29(土) 23:22:00.98

要素アドレスが連続した領域に書き込まれている場合は、
コンパイラがループアンローリングして次の要素アドレスロードしてその参照先のプリフェッチ命令挿入することが可能
ってのを場合によっていくつか先まで出来る
リンクリストの場合はこうはいかない
次の要素のロードが終わらないと次の次の要素のアドレスが分からんのだから

**デフォルトの名無しさん** · 2020/02/29(土) 23:24:07.69

インテルCPUの場合はプリフェッチ入れなくても投機的にプリフェッチされてたからこそ、例の脆弱性が問題になってた

**デフォルトの名無しさん** · 2020/03/01(日) 01:43:44.70

実装法を理解できてないために効率よい使い方を間違っている人は遅さをすぐにキャッシュせいにしてしまう。

**デフォルトの名無しさん** · 2020/03/01(日) 01:49:59.33

>>355
まあそうだが、それだとおまえら一般人はいつまでたってもアホなプログラミングしかできないだろうな。

**デフォルトの名無しさん** · 2020/03/01(日) 01:55:38.98

>>362
俺の人生経験からすると、現実には本当に馬鹿な人にはいくら言っても無駄なようだが。
いくら言っても理解できないし、強く何度も言うと、逆に明らかに絶対やっては駄目なときでもいつもそればっかりやってしまうようになったりする。
なので周りはむしろ困ることになる。

**デフォルトの名無しさん** · 2020/03/01(日) 02:04:09.13

cppreferenceを含めてネットでは std::vector ばかり使われているのは、大部分のプログラマがポインタを理解できないのでリンクリストも理解出来ておらず、使いこなすことが出来ないためと踏んでいる。
正しく理解できないためにstd::listを使うと悪い使い方しかできないため、彼らの実験の仕方ではいつもstd::vectorより遅くなってしまう。
そのような人には、C++を使ってもC#以上の速度を出すことは困難で、だからこそ一般プログラマとそれ以下の人材しか集めることの出来ない多くのプロジェクトでは C#やJava,Rubyなど簡易言語が好まれて使われるようになっていると予想される。
俺とは住む世界が違うので、このことは推定に過ぎないがな。

**デフォルトの名無しさん** · 2020/03/01(日) 02:29:46.23

uint64_t　の型から　unsigned char　の型に変換するにはどうすればよいですか？
同じ4バイトなのでどうにかすれば変換できるのではと思っているのですが。

**デフォルトの名無しさん** · 2020/03/01(日) 02:30:41.70

間違えました。
unsigned charは4バイト確保すれば同じバイト数になる。ですね。

**デフォルトの名無しさん** · 2020/03/01(日) 03:40:24.38

そのマシンのエンディアンの通りに格納したんでいいなら
uint64_t a;
unsigned char b[4];
reinterpret_cast<uint64_t &>(b) = a;

**デフォルトの名無しさん** · 2020/03/01(日) 05:10:36.30

std::vectorばかり使われる最大の理由は、C言語における配列と互換性を持つ唯一のコンテナだからでしょ。

**デフォルトの名無しさん** · 2020/03/01(日) 05:48:12.89

64ビットって4バイトなのか？というつっこみ

**デフォルトの名無しさん** · 2020/03/01(日) 07:40:13.71

あ、そういえば・・・w

**デフォルトの名無しさん** · 2020/03/01(日) 10:25:14.04

>>367
それはだめでしょ

**デフォルトの名無しさん** · 2020/03/01(日) 10:27:14.27

>>367,369
間違えました。
8バイトだからこうなるんですね。
変換後の中身を確認したらエンディアンも問題なさそうです。
ありがとうございました。

uint64_t a;
unsigned char b[8];
reinterpret_cast<uint64_t &>(b) = a;

**デフォルトの名無しさん** · 2020/03/01(日) 11:39:13.66

>>372
動くだろうけどよくないやりかた
reinterpretじゃなくてmemcpyを使う
それかアライメントを合わせる

**デフォルトの名無しさん** · 2020/03/01(日) 12:04:58.71

>>373

ttps://stackoverflow.com/questions/49648033/c-convert-uint64-t-to-unsigned-char-array

上記を参考に下記でやってみたらこれもうまく行っているようです。
こんな感じでしょうか？

uint64_t a;
unsigned char b[8];
memcpy(b, &a, 8);

**デフォルトの名無しさん** · 2020/03/01(日) 12:12:33.01

>>364
あなたが書いてることのレベルが低過ぎて理解できません。

**367** · 2020/03/01(日) 12:13:34.75

ああそうか、アラインメントのこと完全に忘れてたすまん
まぁmemcpy, またはunsigned charにアラインメント指定か、もしくはunsigned charごとに代入した方がいいね
動かす環境が限定されてるならreinterpretでもいいけど

**デフォルトの名無しさん** · 2020/03/01(日) 12:18:16.41

それでいいよ
ちなみにmemcpyの呼び出しコストは最適化で消えるから気にしなくていいよ
(コンパイラ依存だけど)

**デフォルトの名無しさん** · 2020/03/01(日) 12:22:08.16

>>377
ありがとうございます。

**デフォルトの名無しさん** · 2020/03/01(日) 12:42:53.26

追加で質問があります。

http://codepad.org/uN82gnco

この30～31行目でemplace_back()、back()を使っているのですが
emplace_backを使うときはこうやって使うのであってるのでしょうか？

あと、上記をコンパイルすると下記エラーが出ます。

「エラー: オブジェクト以外がメンバ関数 ‘int Self::xxx(ITEM)’ を呼び出すことは出来ません」

今色々調べているのですが、何が悪くてどのように解決すれば良いかがまだわかりません。
どうすればよいかわかりますでしょうか？

**デフォルトの名無しさん** · 2020/03/01(日) 12:44:04.60

>cppreferenceを含めてネットでは std::vector ばかり使われているのは、大部分のプログラマがポインタを理解できないのでリンクリストも理解出来ておらず、使いこなすことが出来ないためと踏んでいる。
よくこんな頭の悪いこと思いつくよなｗ

**デフォルトの名無しさん** · 2020/03/01(日) 12:47:43.45

How can you be so certain?

**蟻人間** ◆T6xkBnTXz7B0 · 2020/03/01(日) 13:00:27.97

Self::xxxをSelfの後に書かないと。
ラムダ内部は別の関数だからthisにはアクセスできない。[&]を使うとか工夫しないと。

**デフォルトの名無しさん** · 2020/03/01(日) 13:19:18.30

>>379
emplaceを試したいならまずは余計なものいれずにやるべきだね

struct ITEM {
　　ITEM(const char* p) : name(p) {}
　　std::string name;
};

std::vector<ITEM> items;
items.emplace_back("ABCD");
for (auto& item : items) {
　　printf("FF %s\n", item.name.c_str());
}

**デフォルトの名無しさん** · 2020/03/01(日) 13:44:18.34

>>382
"&"を使うということは構造体をポインタ渡しするということでしょうか？
下記でポインタ渡しにしたつもりですが、同じようなメッセージが出ました。
ポインタ渡しのことではないのでしょうか？

http://codepad.org/L0oOc9RF

ほぼ同じエラー　→「エラー: オブジェクト以外がメンバ関数 ‘int Self::xxx(ITEM*)’ を呼び出すことは出来ません」

>>383
サンプルありがとうございます。
emplace_back()の時に直接引数に入れることができるんですね。
参考にさせていただきます。
クラス関数に構造体を渡すとエラーになったので、その質問をしたついでにemplace_back()の使い方の質問もさせていただきました。

**デフォルトの名無しさん** · 2020/03/01(日) 13:50:29.27

>>384
> emplace_back()の時に直接引数に入れることができるんですね。

それをやりたいからこそのemplaceだよ
無駄を省きたい上級者用って感じだね
まずは自分でITEMを作ってpush_backで追加するのが基本だと思うよ

**デフォルトの名無しさん** · 2020/03/01(日) 13:52:07.36

違う違う、[](ITEM& item) を[&](ITEM& item)にしろってこと

**デフォルトの名無しさん** · 2020/03/01(日) 14:10:29.25

>>385
emplace_backは新しい文法でpush_backの方が従来のもののようですね。

>>386
その対応でエラーが消えました。
[&]が何してるのかまだ理解できていないので調べてみようと思います。
ありがとうございました。

**デフォルトの名無しさん** · 2020/03/01(日) 14:23:08.70

あっと、[&](ITEM& item)より[this](ITEM& item)のほうがよかったか

**デフォルトの名無しさん** · 2020/03/01(日) 15:44:10.68

>>388
thisでもいけました。
数値のmemcpyを教えていただいた >>374 の件ですが、下記で確認するとバイト単位で逆になりました。
エンディアンの影響だと思いますが、unsigned charに反転せずに簡単にセットする方法はなにかありますでしょうか？

unsigned short num = 258;
unsigned char temp[2];
memcpy(temp, &num, 2);

printf("A %04X\n", num);
printf("B %02X%02X\n", temp[0], temp[1]);

下記結果になる。

A 0102
B 0201

**デフォルトの名無しさん** · 2020/03/01(日) 16:31:11.59

>>389
調子にのりすぎ
原因わかってんなら自分で解決できるだろ
頭使え

**デフォルトの名無しさん** · 2020/03/01(日) 16:36:04.92

>>390

すみません。
センスないような気がしますが下記で入れ替えようと思います。

unsigned char temp1[2];
unsigned char temp2[2];
memcpy(temp1, &num, 2);
temp2[0] = temp1[1];
temp2[1] = temp1[0];

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/01(日) 17:16:47.98

>>391
htons を使えばいいんじゃね？
言語仕様にあるわけじゃないけど、 POSIX と Windows で使えるからまあおおよそポータブルでしょ。

**デフォルトの名無しさん** · 2020/03/01(日) 18:19:09.36

>>391
素直に
temp[0] = (num >> 8) & 0xff;
temp[1] = (num >> 0) & 0xff;
でよくね？

**デフォルトの名無しさん** · 2020/03/01(日) 18:30:07.18

C++の初心者質問スレってなかったっけ

**デフォルトの名無しさん** · 2020/03/01(日) 18:38:25.85

>>372
コピーも何も必要なくて、
uint64_t a;
BYTE *ptr = (BYTE *)&a;
ptr[0] : 0 バイト目
ptr[1] : 1 バイト目
・・・
ptr[7] : 7 バイト目
でいける。

**デフォルトの名無しさん** · 2020/03/01(日) 18:41:25.44

>>395
さらに、
union UUU {
uint64_t　 m_u64;
BYTE　　　m_b[8];
};
uint64_t　　a;　　　// 入力値
UUU　　u;
u.m_u64 = a;
とすれば、
u.m_b[0] // 0 バイト目
・・・
u.m_b[7] // 7 バイト目
となる。

**デフォルトの名無しさん** · 2020/03/01(日) 19:07:30.68

>>396
それc++ではUBだよ
あれ君って天才君だっけ？

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/01(日) 21:11:13.32

汎用的に作るならこんな感じかな？

#include <type_traits>

template<class T>
typename std::enable_if<std::is_integral<T>::value && std::is_unsigned<T>::value, void>::type
integral_to_bytes(T n, std::uint8_t* dest) {
for(std::size_t i=sizeof(n)-1; i<sizeof(n); i--, n/=256) dest[i] = n%256;
}

**デフォルトの名無しさん** · 2020/03/01(日) 21:22:32.67

std::array<uint8_t, sizeof(T)>を返す方が親切だぞ

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/01(日) 21:50:36.45

>>399
なるほど。
整数型の大きさだからそれほど大きくなることは心配しなくていいもんな。

**デフォルトの名無しさん** · 2020/03/01(日) 22:10:49.73

OMP_STACKSIZEが小さいとセグフォるが1Gとか指定してもいいんか？

**デフォルトの名無しさん** · 2020/03/02(月) 01:26:05.82

>>397
UBという証拠は？

**デフォルトの名無しさん** · 2020/03/02(月) 01:46:27.25

>>397
少なくともちゃんと例としては使われている：
https://aticleworld.com/little-and-big-endian-importance/

**デフォルトの名無しさん** · 2020/03/02(月) 01:47:31.58

>>403
typedef union
{
uint32_t u32RawData;
uint8_t au8DataBuff[4];
} RawData;
uint32_t ChangeEndianness(uint32_t u32Value)
{
RawData uChangeData,uOrginalData;
uOrginalData.u32RawData = u32Value;
//change the value
uChangeData.au8DataBuff[0] = uOrginalData.au8DataBuff[3];
uChangeData.au8DataBuff[1] = uOrginalData.au8DataBuff[2];
uChangeData.au8DataBuff[2] = uOrginalData.au8DataBuff[1];
uChangeData.au8DataBuff[3] = uOrginalData.au8DataBuff[0];
return (uChangeData.u32RawData);
}

**デフォルトの名無しさん** · 2020/03/02(月) 02:13:31.73

C/C++では高速化のためCPUのマシン・アーキテクチャをそのまま使う。
マシン・アーキテクチャによって little endian と big endian の違いが有るのでC++言語仕様としては定義されてないが、「but most compilers define」なっている。
これはつまり、littele endian の CPUなら、そのまま little endian での表現がそのまま読みとられ、big endian の CPUなら、そのまま big endian での表現がそのまま読み取られることを意味している。
たとえば、cppreference では、
「reading from n or c is UB but most compilers define it」
となっており、
32BIT値の 0x12345678の場合に、unionで 16BIT 配列の0要素目に0x0011を代入すると、
0x12340011 or 0x00115678
が読み取られるように書いてある。
undefined behaviour であっても、このどちらかに限定されると言うことであろう。

https://en.cppreference.com/w/cpp/language/union

union S
{
　　std::int32_t n;　　 // occupies 4 bytes
　　std::uint16_t s[2]; // occupies 4 bytes
　　std::uint8_t c;　　 // occupies 1 byte
};　　　　　　　　　　　// the whole union occupies 4 bytes

int main()
{
　　S s = {0x12345678}; // initializes the first member, s.n is now the active member
　　// at this point, reading from s.s or s.c is undefined behavior
　　std::cout << std::hex << "s.n = " << s.n << '\n';
　　s.s[0] = 0x0011; // s.s is now the active member
　　// at this point, reading from n or c is UB but most compilers define it
　　std::cout << "s.c is now " << +s.c << '\n' // 11 or 00, depending on platform
　　　　　　　<< "s.n is now " << s.n << '\n'; // 12340011 or 00115678
}

**デフォルトの名無しさん** · 2020/03/02(月) 04:24:33.89

先月ぼくが通った道だけど、結論が全く違ってて興味深い。

**デフォルトの名無しさん** · 2020/03/02(月) 08:40:39.81

UBの恐ろしさを知らない子の結論だね
若いなあ

**デフォルトの名無しさん** · 2020/03/02(月) 08:56:34.60

老害なのか子なのかどっちかにしろ

**デフォルトの名無しさん** · 2020/03/02(月) 09:31:30.94

>>403
cではOKなんだよ
だからわざわざc++ではって限定したんだから察せよ
cでは定義されてるから多くのコンパイラーはc++でも同様の解釈する
また実際のところ今後ずっとそうだろう(今回のケースに限っては)
でもUBはUB
屁理屈つけて自己正当化しようともそれは変わらない
エンディアンでなくライフタイムの問題でしょ、c++の常識的に

**デフォルトの名無しさん** · 2020/03/02(月) 09:37:25.38

くっそしょーもねえ

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/02(月) 10:51:20.25

>>405
ほとんどの場合に大丈夫だろうという見立ては間違ってないと私も思う。
で、大丈夫でなかったときは？
たぶんコンパイルエラーにも警告にもなることなく黙って未定義動作に突入する。

各処理系・環境での挙動が保証されている (検証が済んでいる) なら別に使ってもいいんじゃないのとは思うけど、
union を使ってすごく良くなるというわけでもないので、あえてやることもないんじゃないのとも思う。
少なくとも最初は選択肢から外すなぁ。

**デフォルトの名無しさん** · 2020/03/02(月) 13:35:46.29

本人わかってんだからそんな必死になって噛み付くようなことでもないだろ
だいたいプラットフォーム全く限定せずにC++でソフトが書けるのかと

>>411
＞たぶんコンパイルエラーにも警告にもなることなく黙って未定義動作に突入する。
アホか
普段警告レベル下げてるから気付かねーんだよ

**デフォルトの名無しさん** · 2020/03/02(月) 15:19:49.70

**デフォルトの名無しさん** · 2020/03/02(月) 15:20:44.34

(↑のv はミスしました)
>>409 >>411
実は、union より、>>395 のように単純に書いたほうが良い。
unionの場合は、最初に代入によるコピー動作が入るが、>>395 は、単に 64bit 整数の入っている変数のアドレスを取得しているだけだから、全くコピー動作が入らず、物凄く効率が良いし、未定義動作でもない。
>>395 が未定義動作というなら、Cの根幹が揺るぐ。

**デフォルトの名無しさん** · 2020/03/02(月) 15:23:49.36

>>409
little endian と big endian の違いだけで全面的にUBということではないはず。
unionの仕様からいえば、ちゃんと 64BIT 整数をそのままイメージとして投影したものがバイト配列になって取得できるはず。
それがunionの定義なのだから。
sizeof(union型)とsizeof(unionのメンバ)の関係も定義されているので、それ以外の実装は有り得ないはず。

**デフォルトの名無しさん** · 2020/03/02(月) 15:28:47.95

>>415
お前は人のレスよく読め
cの話はしてないんだよ

**デフォルトの名無しさん** · 2020/03/02(月) 15:43:11.75

private/protectedで隠されているわけでもないPODの
ビット表現に依存するなってのは理に適わない
規格が保証しないなら自己責任というだけの話
そんなんどこにでもいくらでもある

**デフォルトの名無しさん** · 2020/03/02(月) 16:18:13.98

test

**デフォルトの名無しさん** · 2020/03/02(月) 16:23:29.71

>>416
>>396 で言えば、m_u64, m_b メンバの先頭アドレスがどちらも offset 0 から始まっている限り、little endian と big endian の違いを除いては、どんな処理系でも、m_64 のメモリ中での表現がそのままバイト配列 m_b[] に投影されて読み出せる。
それがunionの定義。
メンバがすべて「offset 0」に配置されるかは、アラインだけの問題。

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/02(月) 16:39:58.55

>>415
規格では全面的に UB だよ。
C++11 の 9.5 を確認してみたんだけど、
共用体で保証されているのは

- 直近で入れたのと同じメンバで取りだす場合
- 先頭部分に共通する型を持つ標準レイアウトの型をメンバとして持つ共用体であれば共通部分を使うのはアリ (← 言い回しがややこしくてスマン)

ってことだけで、あくまでも先頭に適合する型が連続する部分に限って許してる。
そんでもってこれは規格の書き方はちょっと違うだけで C でも同じだわ。

**デフォルトの名無しさん** · 2020/03/02(月) 16:44:13.99

>>419
自称天才さんですらUBであることは認めてんのにお前ときたらw
まぁ後は好きにどうぞ

**デフォルトの名無しさん** · 2020/03/02(月) 16:57:58.17

コンピュータはチューリングマシンではない!!!

理由 ---- timeGetTime();

マザボの時計は計算不可能的だ、時計を計算できる「アルゴリズム」は存在しない

理由2 multi-thread チューリングマシンはシングルスレッド的だ
理由3 multi-process シングルスレッドで並列計算を真似る
―― つまり、チューリングマシンなる理論自体はそもそも間違っている！
なぜなら単一のチューリングマシンは並列計算を真似ることができる
つまり、チューリングマシン自体は矛盾している！
(たとえば p->Update(); q->Update(); これはシングルスレッドのコードだ、
つまり、単一のチューリングマシンだ、しかし実行時の効果は並列的だ！)

**デフォルトの名無しさん** · 2020/03/02(月) 17:05:20.01

char配列とunionにしてバイトアクセスなんて
みんな自己責任でやってるに決まってるだろうが

そこへ、その案件の関係者でない者が頼まれもしないのにしゃしゃり出て
「UBだ」とキリるのが格好いいと思っているのはそいつ自身だけだ

**デフォルトの名無しさん** · 2020/03/02(月) 17:40:48.54

>>423
分かってる奴が自己責任でやってるだけなら誰も止めないよ。
今回の場合、初心者の質問(>>389)に対し自称上級者がunionを使う方法(>>396)を提示したから、それはUBだと突っ込まれたんだろ。
別にUBを指摘することがカッコ良い訳ではないけど、指摘されて真っ赤になることはカッコ悪いぞw

**デフォルトの名無しさん** · 2020/03/02(月) 17:44:58.26

ああ、＝にしたいわけね
いいよ別に
こっちも証明できねえし

ただ、おまえさんのアドバイスは俺の胸には全く響いていない
その事実が変わらん限り痛くも痒くもない

**デフォルトの名無しさん** · 2020/03/02(月) 17:45:42.25

>>420
しかし、メンバのアラインの問題さえクリアしていれば、union中の2つのメンバの
offset address は共に0になる。
そして、以下の通りなので、メモリ中の同じアドレスから読み書きすることになるので、C++の仕様に明示されていなくても、m_b[k] の動作は単純に、m_u64のメモリ中のイメージをそのまま先頭から読み書きすることになる。
なので、問題が起きるとすれば m_u64 と m_b のアラインの問題のみだ。
もし、アラインが合わなかった場合には、m_b[k] が k == 0 でも、m_u64 の途中のアドレスから読み出すことになったりする事になる。
しかし、この様な場合に m_u64 と m_b のアラインが合わない処理系は多分、珍しい。

union UUU {
　　uint64_t　m_u64;
　　BYTE　　　m_b[8];
};
UUU xx;

xx.m_u64 // もうこの段階で、コンパイラ内部では m_u64 が元々 union のメンバであったという情報は消えることになることが C/C++ の仕様では保障されている。。
xx.m_b[k] // もうこの段階で、コンパイラ内部では m_b が元々 union のメンバであったという情報は消えることになることが C/C++ の仕様では保障されている。。

**デフォルトの名無しさん** · 2020/03/02(月) 17:47:34.63

>>423
自己責任とかじゃねーっての
cでは合法的なtype punning
お前strict aliasing理解してるか？

**デフォルトの名無しさん** · 2020/03/02(月) 17:53:08.73

やっぱりUBの怖さ全然わかってない子か
おっしゃる通りオフセットのアドレスはたまたま一緒かもしれないし、規格を読み解けば論理的にそうなるべきであることは導けるのかもしれない
だけどそれが何だというのか？
そのオフセット値から読み取ってくれることや、そもそも読み取り動作をしてくれるとどうして言い切れる？
未定義動作ではコンパイラが何をするのも何をしないのも完全に自由だということをお忘れなく

**デフォルトの名無しさん** · 2020/03/02(月) 17:53:41.95

https://stackoverflow.com/questions/25664848/unions-and-type-punning

4. THE SAFE CASE: unsigned char

The only safe manner of using type punning is with unsigned char or well unsigned char arrays (because we know that members of array objects are strictly contiguous and there is not any padding bytes when their size is computed with sizeof()).

　union {
　　 TYPE data;
　　 unsigned char type_punning[sizeof(TYPE)];
　} xx;　
Since we know that unsigned char is represented in strict binary form, without padding bits, the type punning can be used here to take a look to the binary represention of the member data.
This tool can be used to analyze how values of a given type are represented, in a particular implementation.

I am not able to see another safe and useful application of type punning under the standard specifications.

**デフォルトの名無しさん** · 2020/03/02(月) 17:55:17.52

>>427
いーや自己責任だ
おまえさんが知らないだけ

どの案件の関係者でもなさそうだな

**デフォルトの名無しさん** · 2020/03/02(月) 17:56:57.42

>>429
その回答の下に「Cだけだろ」ってツッコミ入ってるだろ
このあわてんぼうさんめ

**デフォルトの名無しさん** · 2020/03/02(月) 18:18:40.49

>>430
何を根拠もなく断言しとんねんこの老害
cppreferenceはっとく
これ基本的に規格に書かれてる文と同じだ
かつこれはcにしか書かれてない
c++のは下にリンクあるから読んどけ

ttps://ja.cppreference.com/w/c/language/union
共用体の内容をアクセスするために使用されるメンバが、値を格納するために最後に使用されたメンバと同じでない場合は、格納された値のオブジェクト表現が新しい型のオブジェクト表現として再解釈されます (型のパンニングと言います)。

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/02(月) 18:26:04.80

>>426
メモリのレイアウトの話だけならそれ以外の選択肢は実質的にないだろってのはわかるよ。
そりゃそうだ。
実質的にそうだってのは今さら言わなくても知ってる。

いまどきの C++ コンパイラは未定義の挙動はどうなってもいいことを前提にした最適化をすることがあるんだよ……。
去年には LLVM が const 変数への代入を削除するってのでニュースになっただろ。
https://developers.srad.jp/story/19/09/27/1626210/
const 変数は変更されない。それが前提なんだから変更されても知らんってわけ。

今まで緩く対応してたのが厳しくなることだってある。
共用体が使われる場面ってのはメモリのレイアウトを利用したい場合ってのは多いから
現実には急に挙動を変えるなんてことはないと思うけど、
未定義を警戒するのは最適化に対する警戒なんだよ。

**デフォルトの名無しさん** · 2020/03/02(月) 18:29:44.89

このスレみててなんとなく餃子くいたくなったからスーパーいったけど
売りきれてたわ

**デフォルトの名無しさん** · 2020/03/02(月) 18:33:24.10

>>432
次も非常に重要：
「共用体へのポインタは、そのいずれのメンバへのポインタにもキャストできます (共用体がビットフィールドを持つ場合は、共用体へのポインタはそのビットフィールドのベースとなる型へのポインタにキャストできます)。
同様に、共用体のいずれのメンバへのポインタも、囲っている共用体へのポインタにキャストできます。」

これは、union においては、全てのメンバの先頭アドレスが、すべてoffset 0から始まることが保障されていることを意味する。

なので、>>426のアラインの心配はない事になる。

**デフォルトの名無しさん** · 2020/03/02(月) 18:34:36.46

>>435
もとい。良く考えてみるとそうでもなかった。
unionへ、または、unionから cast する際にコンパイラが何らかの offset 値を足したり引いたりする可能性があるため。