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/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 値を足したり引いたりする可能性があるため。

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

>>432
もう一度言う
どの案件の関係者でもなさそうだな

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/02(月) 19:05:25.24

>>437
おっ。立場を持ち出すのか？
理屈では反論する余地がないという意味？

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

お？　＝ってことでいいのか？
ID変えるとか超しょーもねーねらーだなｗ

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/02(月) 19:29:50.21

>>439
俺は煽ってるだけだよ。

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

>>433
「const 変数を cast してから代入する」というのはそもそも元々禁止事項だから、今回の話とはかなり違う。

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/02(月) 19:35:17.26

>>441
禁止と未定義の間に差があるという誤解？

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

>>407, >>438
こいつらすごい嬉しそう
こういうのでしか偉そうに出来ないんだろうなぁ

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

>>445
>>442 には、以下の用になっている：
// 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

「 11 or 00, depending on platform」
「12340011 or 00115678」

数学的に
A or B
ということは、A または Bに限られると言うことで、それ以外の可能性がないことである。

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

いや、さすがにそれは「大抵のコンパイラはどちらかに定義する」だから
そうじゃないのも有り得る

ただそんな変な環境まで想定するのも非現実的だし
それを言うなら1byte=8bitsとも限らないんで、そんな環境だとuint8_tもおそらく定義されておらず
はちみつがドヤ顔で自称汎用的だと挙げた>>398も使えないわけだが

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/02(月) 19:58:23.59

>>444
それだったら UB という語を使うのがおかしいよ。
C++ (の仕様) 的には UB ってのは正しいプログラムには存在してはいけないものだ。
どちらになるのか不定という意味では普通は使わない。

11 or 00 は most compilers define it に対応してるとも解釈するのが自然だと思うよ。

>>445
せやな。
そこを言うと汎用的とは言えないな。
unsigned char で定義した方が確実だったか……。

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/02(月) 20:14:13.91

C++20 では負数は2の補数形式で定義されることになったみたい。
C++ の最新規格に追従しているコンパイラは全部 2 の補数を前提にしてたからもう 1 の補数はええやろみたいな話を聞いた。

そこまで決めるのになんで1バイトの大きさは明記しないんだろ。
1 バイトが 8 ビットじゃないアーキテクチャ (で主要 C++ コンパイラがサポートしている環境) が有るんかね？

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/02(月) 20:17:54.52

>>445
十分に汎用的とは言えないけど使えないときはコンパイルエラーになるだろうから比較的マシということで勘弁。

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

>>440
超しょーもねーねらー認めやがったｗ

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

>>447
signedのwrap aroundは定義された？

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/02(月) 20:37:53.23

>>449
ID 変えとかはしてないからね。
いまどき匿名プロキシとかあんまりないし。
俺がトリップを付けないのはつまらない質問するときだけ！
(つまらないこと聞くの恥ずかしいじゃん……///)

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

>>451
人のことを＝っといて虫のいいことを言うな
人間としてどうなのか疑っちまうぜ

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

敗走したのにもどってくんなよ

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/02(月) 20:45:07.72

>>450
されてない。それは従来通り。
何故なのか……。

**蟻人間** ◆T6xkBnTXz7B0 · 2020/03/02(月) 21:47:32.89

【ソフト名】リソーエディタ
【URL】https://github.com/katahiromz/RisohEditor
【説明】リソースデータを編集できるソフト。

これ、VS2012でビルドしたら、バイナリサイズが10MB超えてるだけど、なんとか6MB以内に縮小できないだろうか？

インラインとか関係ある？

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/02(月) 22:01:25.31

>>455
デバッグ情報は取り除いてそのサイズ？
サイズだけが重要なら UPX とか使えばいいんでね。

**蟻人間** ◆T6xkBnTXz7B0 · 2020/03/02(月) 22:10:19.07

>>456
うん。zip圧縮したサイズがだいたい10MB。UPXも試したけど圧縮後のサイズには効果が薄いみたい。インライン関数がデカいのがまずいのかな？

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

>>457
サイズ優先の最適化オプション試してみたら

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

そもそも >>398 って、割り算と剰余まで使っていて、実用的なコードとは
言いがたい。
せめて、x >>=8 と x & 255 ならまだましだが、そもそも >>395
で十分なのに、敢えて複雑にして、逆にバグが入る可能性も高い。
それと、厳密に言えば、誰かも指摘したように unsigned char が 8bit かどうか
も C や C++ の仕様としては決まってないようだし。

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

>>398
それはバイトの概念を直接扱えないような言語でも使えると言えば使えるかもしれないが、敢えてそんなコードを書く必要はない。
「高級アセンブラ」の名が無く。

自分が知らない処理系に誰かがコンパイルすることを想定していて不安が残る場合には、どこかに
テストコードを書いておけばいい。例えば、次のようにする：
uint32_t a = 0x11223344;
uint8_t *ptr = (uint8_t *)&a;
if ( ptr[0] == 0x44 && ptr[1] == 0x33 && ptr[2] == 0x22 && ptr[3] == 0x11 ) {
　// リトルエンディアン
}
else if ( ptr[0] == 0x11 && ptr[1] == 0x22 && ptr[2] == 0x33 && ptr[3] == 0x44 ) {
　 // ビッグエンディアン
}
else {
　// エラー
}

**デフォルトの名無しさん** · 2020/03/03(火) 00:10:54.51

ちなみにC++20からエンディアンも標準に入る

https://cpprefjp.github.io/reference/bit/endian.html

使えるかは知らない...

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

CではOK、C++ではUB
C/C++コンパイラではたまたま動く場合が多いかもしれないけど、UBはUBなんだし回避方法もあるんだからやめとこう
ただこれだけの話なんだけど

何が気に食わないのか「わかりやすいんだ！汎用的なんだ！Cらしいんだ！俺のコンパイラでは動くんだ！この程度のテクニックも知らんのか！」
ってノリでナイーブにUB書きたがる奴が絶えないのはなんでだろうね
一度でもそういうのが引き起こす地獄みたいなバグに付き合わされたら二度とそんなことしないしさせないって思うもんなんだけどね
幸運にも遭遇したことがないのか、全部他人に解決してもらってるいい身分の人なのか

**デフォルトの名無しさん** · 2020/03/03(火) 02:22:47.77

> やめとこう

何の権利で指図するんだよ

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

「そんなにお酒飲み過ぎると健康に悪いよ、やめとこう？」
「一生酒を飲むなと命令するのか！何の権利で指図するんだ！」

おおめんどくさい
ただのアドバイスを命令や強要や脅迫に感じるのは鬱の初期症状だから気を付けなよ

**デフォルトの名無しさん** · 2020/03/03(火) 03:15:03.15

お節介なやつは人からそう見られてるんだよ

**デフォルトの名無しさん** · 2020/03/03(火) 03:39:42.34

お節介じゃないよ
俺の関係者がここを見てここのバカに勇気付けられてUB書き散らかすようになると俺が困るから言ってるんだよ
俺のためだ

**デフォルトの名無しさん** · 2020/03/03(火) 03:54:38.06

逆もしかりだ
チームに入ったばかりの新入りが「UBだ！ UBだ！」と喚きだし
「おまえならどうする？」に答えられないゴミには諦めてもらうしかない
どうせunion使わないためにポインタのキャストとかだろくっだらねえ

**デフォルトの名無しさん** · 2020/03/03(火) 04:29:39.93

新入りに危険な書き方を指摘されたら「くっだらねえ」と逆ギレした上に
チームで規格を当たって検討もせずに新入りに解決策を丸投げするのか
最低だなお前

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/03(火) 05:43:51.35

>>459-460
まともなコンパイラはビット演算に置き換える最適化が入ることが期待できるんだから、
割り算が実用的でないなんてことはないよ。
エンディアンの影響を避けるには良い選択のひとつだ。

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/03(火) 06:03:20.43

ガチで組み込み環境のシビアなやつだとバイナリのテストの方に時間をかけたりするから
逆に言語に無頓着になる場合があるというのは聞いたことは有る。

1998 年頃の自動車制御とか携帯電話とかの話なんで、
コンパイラの規格準拠具合もそれほどあてにできなかった時代の話だけど。

**デフォルトの名無しさん** · 2020/03/03(火) 06:14:57.83

数年前に触ったdspは1byte32bitだったなー

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/03(火) 06:36:20.05

>>455
実行ファイル本体はさほど大きくないじゃん。
一番大きいのは cc1.exe か……。
これって必要？

**デフォルトの名無しさん** · 2020/03/03(火) 06:43:09.65

>>468
例えばmemcpyの各プラットフォームごとに向けた最適化(の元のソース)はお前がここで言うようなUBだらけだろうし
boostなんかも各プラットフォーム向けに分けて書かれてる部分が多い
そこまでUBを避けてどんなプラットフォームでも動くように、なんてのもYAGNIの一種だと思うけどね

**デフォルトの名無しさん** · 2020/03/03(火) 06:46:29.83

>>470
ガチな組込みって言うか普通の企業なら開発環境も決め打ちで作ってテストする

**デフォルトの名無しさん** · 2020/03/03(火) 06:53:54.29

>>445 > それを言うなら1byte=8bitsとも限らないんで
>>447 > 1 バイトが 8 ビットじゃないアーキテクチャ (で主要 C++ コンパイラがサポートしている環境) が有るんかね？
>>471 > 数年前に触ったdspは1byte32bitだったなー

1byteは8bitと決まってるんですけど…

**デフォルトの名無しさん** · 2020/03/03(火) 07:14:47.35

え？

**デフォルトの名無しさん** · 2020/03/03(火) 07:16:59.86

なぜuint8_tを使わないの？？、、

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

>>475
え？

**デフォルトの名無しさん** · 2020/03/03(火) 07:30:20.60

2008年に一応はっきり決まったらしいね
ただしC++ではそうと決めてはいないので一応UB

**デフォルトの名無しさん** · 2020/03/03(火) 07:33:02.45

>>473
たぶん根本的なところで他人の発言が理解できてない
言いたいことはわかるけど、もはや議論になってないから黙ってろ

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/03(火) 07:36:41.10

>>473
各プラットフォームに「対応」できてるなら別にいいんじゃね。
union の未定義がどうこう言ってるのは >>365 程度のことに
あえて各プラットフォームの事情を持ち込むのは割に合わない (そのくらい UB の厄介さには重みがある)
って話題だと俺は理解してる。

ターゲットが完全に固定されてたとしてもコンパイラが吐くコードを把握する自信は俺はないし
たぶん >>468 もないし、 >>473 だって出来れば避けて通りたくない？
その上でどうしてもいじらないといけないくらい速度に厳しい場面とかだったら嫌々やるかもしれないけど、
最初からはやらないって程度の話。早すぎる最適化は諸悪の根源っていうし。

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/03(火) 07:38:19.27

>>475
少なくとも C/C++ では決まってない。

>>477
対応する大きさの型の別名として定義される。
その大きさの型が存在しない場合は定義されるべきではないことになっている。
無ければコンパイルエラーになるだけなんで本当に 8bit キッカリであることが大切なら
uint8_t を使うべきだけれど、「1 バイト」という意味で uint8_t を使っちゃうと C++ の仕様に厳密な意味では
十分に汎用的であるとは言い難い。

ま、そんな環境はあんまりないんだけど組み込み環境だとたまにあるっぽい。

>>479
UB ではなく処理系定義というべき

**デフォルトの名無しさん** · 2020/03/03(火) 07:45:28.78

>>480-481
あのさ、一応UBってことはすぐ指摘されて本人もわかってんだよ、質問者もとっくに見てるはず
>>407辺りから意味無くマウント取るような言い方する奴(はちみつ含む)が出たから荒れてんだろ
そこまで言うなら今現在存在する環境でunionによるtype punningが出来ない環境を挙げてみろ
おそらくどこかにはあるんだろうが、1byte=8bitでない環境はすでに挙げられてるのにunionの方は全く例が出て来ない
>>480
理解出来てないのはお前だ

**デフォルトの名無しさん** · 2020/03/03(火) 07:47:02.82

>>482
> 少なくとも C/C++ では決まってない。
決まっていないという根拠よろしく

**デフォルトの名無しさん** · 2020/03/03(火) 07:50:44.52

>>484
自分で調べろ

**デフォルトの名無しさん** · 2020/03/03(火) 08:03:53.36

>>483
UBだってことは分かってる、ぼくは>>407でカチンときて怒ってるだけだ、ってことだろ。もうただの口喧嘩でこれ以上何も議論することは無いんだからさっさと終わりにしなよ。

**デフォルトの名無しさん** · 2020/03/03(火) 08:07:38.96

お前もたいがい煽ってると思うが

>終わりにしなよ
俺に言うなよ

**デフォルトの名無しさん** · 2020/03/03(火) 08:22:51.66

>>485
傍から低能丸出しのレスかよ…
何を馬鹿にしてるのかもわかってないだろw

**デフォルトの名無しさん** · 2020/03/03(火) 08:23:01.86

>>483
> そこまで言うなら今現在存在する環境でunionによるtype punningが出来ない環境を挙げてみろ

↓こういう例は把握してるの？ >>405 みたいな理解だとこんなコードもエイリアス有効という話になっちゃいそうで危ないと思う。
https://wandbox.org/permlink/qrUVwDZbNPRnOQyN

#include <stdio.h>
#include <stdint.h>
int f(uint16_t* u16, uint32_t* u32) { *u16 = 0x1111; *u32 = 0x22222222; return *u16 + *u32; }
union U { uint16_t u16; uint32_t u32; };
int main() { union U u; printf("%08x\n", f(&u.u16, &u.u32)); }

出力 (gcc 9.2.0 -O2):
22223333

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/03(火) 08:31:00.08

>>483
実際に有るか無いかなんて知らんよ。
俺は検証するのが割に合わんから可能なら避けるし、 >>365 程度のことに「あえて」使いたいという気持ちはわからんと言ってる。

俺は何がなんでも UB は絶対にダメなんてことは書いてないし、十分に検証できてるものにまで文句は付けんよ。

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/03(火) 08:45:51.11

>>484
- std::uint8_t は cstdint にある。 (C++17 の 21.4.1)
- cstdint は C 標準ライブラリヘッダの stdint.h と同じように全ての型とマクロを定義する (同上)
- C++17 が参照する C の規格とは C11 (ISO/IEC 9899:2011) である (C++17 の 2)
- uintN_t はオプショナルだが 8, 16, 32, 64 については対応する型が存在するなら提供しなければならない (C11 の 7.20.1.1)
- char が 8bit ならば C++ には uint8_t は必ず存在するはずだがオプショナルであると言ってるから 8bit の型がない (char が 8bit ではない) ことは想定内なんだろう

というのが根拠。

**デフォルトの名無しさん** · 2020/03/03(火) 08:49:11.40

いわゆる「悪魔の証明」ですか。

**デフォルトの名無しさん** · 2020/03/03(火) 08:50:30.01

>>489
strict aliasing rulesに対する違反にまで話広げてるんだろうけど
さすがにそこまで擁護する気は無いし自己責任じゃないの
そこまで悪質なコードになると話違ってくる

>>490
いやいや、一般的な環境で>>396みたいなのは検証するまでもないから
だいたい昔は未定義だったのが最近の仕様で変わったのもあるだろ

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/03(火) 09:13:15.69

>>493
検証するまでもないという確信を持てる程度に (その現場か個人の経験として) 実績があるってことでしょ。
本当に何もないところで確信を持ってるんだったらそれはそれで駄目だと思う。

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

>>467
> どうせunion使わないためにポインタのキャストとかだろくっだらねえ

アウト
なぜunion使うかの前提すら理解してない