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/ (日本語)

**はちみつ餃子** ◆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使うかの前提すら理解してない

**蟻人間** ◆T6xkBnTXz7B0 · 2020/03/03(火) 10:41:55.49

>>472
必要ないファイルを削ったら3MBになった。ありがとう。

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

ちなみに>>489の例はunionじゃなくて同じ変数を指すポインタ渡しても同じことになるからね

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

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

今時点では知らないしないだろうな
でも今後もそうなのかはわからない

1byteの定義なんかは処理系がターゲットcpuごとに決めるもの
エンディアンとかも
これは問題視されない

unionに関しては、そういう類いではないだろう
理由は把握してないけど、非podの場合を含めて意味論が決められない、
あるいはaliasingに関係して明確に使うなということなのかもしれない

あえてcと非互換にしているわけで、グレーであることは知っておくべき

ちなみに20からpodという文言が消えると聞いた
さらにcとの乖離が進むのかもしれない

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

>>491
で、そのどこにバイトの話があるんだ？

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

CHAR_BITS の定義でしょ
自分で確認しろ

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

POD=trivial&&standard-layout
ってC++11の時に整理済みでしょ
概念は消えないよ

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

>>489
それはgccのバグに思える。

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

バグじゃないぞ
これがバグだったら最適化にかなりの制限がかかってしまう
strict aliasing ruleでググれ

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

>>503
最適化しない場合とした場合とで結果が変わってくるのは駄目な最適化。

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

だからググれって
鬼の首を取ったかのように叩く奴が出てくる前に教えてやってんのにw

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

>>499
肝心なことが漏れてた。すまぬ。

C++17 だと 4.4 の脚注に

> The number of bits in a byte is reported by the macro CHAR_BIT in the header <climits>

とあって、バイトとは char の大きさのことだというのが C++ での考え方だと思っていい。

C11 だと 5.2.4.2.1 の CHAR_BIT の説明のところに

> Their implementation-defined values shall be equal or greater in agnitude
> (absolute value) to those shown, with the same sign.
>
> - number of bits for smallest object that is not a bit-field (byte)
> CHAR_BIT 8

という言い回しがあって、 CHAR_BIT は 8 以上であればいい (8 キッカリとは限らない) と解釈できる。
それと、ポインタを持てる単位がバイトだということが示唆されているとも言える。

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

>>491
charのbit数は決まってないが、バイトはコンピュータ用語として8バイトと決まっているはず。

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

>>506
多分、
「The number of bits in a byte is reported by the macro CHAR_BIT in the header <climits>」
は、書き間違いで、正しくは、
The number of bits in a char is reported by the macro CHAR_BIT in the header <climits>
だと思われる。

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

>>507
そうか、歴史的には、byteが7bitだったこともあったんだね。

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

>>507
これな。
https://ja.wikipedia.org/wiki/IEC_80000-13
C++ が参照規格として示してないので採用してないんでしょ。

まあそんなこと言ったら英単語の意味だってどうとでもとりようがあったりするからアレだけど、
あらためて C++ の規格の中でバイトについて書いてある以上は C++ 世界では
「コンピュータ用語としてのバイト」を採用してないと解釈するのが自然。

将来的には変更されることもあるかもしれんけども。

>>508
C++20 のドラフトでもそのままなので本気で間違ってると思うなら指摘してあげればいいんじゃね？

>>509
9bit のマシンもあったらしいよ。
https://ja.wikipedia.org/wiki/ACOS-6

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

>>501
概念消えるとは言ってないけど
今回文言消す理由ってなんなの？
何も知らずに口挟むとは思えないから質問させてくれ

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/03(火) 14:19:12.58

>>511
もう POD という区分が適切な場面はあんまりないから、という意味のことが書いてあるっぽい。
https://botondballo.wordpress.com/2017/11/20/trip-report-c-standards-meeting-in-albuquerque-november-2017/

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

trivialは生成解体の話で、standard-layoutはデータ配置の話だから
PODってのはレイヤーの違う性質が混ざってて規格に使う用語としては筋悪なんですわ

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

>>510
>C++20 のドラフトでもそのままなので本気で間違ってると思うなら指摘してあげればいいんじゃね？
annotated C++ reference manual, 3.2.1c Integral Limits には、
CHAR_BIT　　　8　　maximum bits in a byte
とあった。

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

>>514
ANSI/ISO, Standard C プログラマーズリファレンス
P.J. Plauger / Jim Brodie, 日本語訳, ASCII

第一部第一章基本整数型には、
--------------------------------------------------------
表記,　　　　最小範囲,　表現における制限
--------------------------------------------------------
char,　　　　 [0,128),　　signed char か unsigned char のどちらかと等しい。
signed char,　(-128,128), 少なくとも 8bit 精度の符号付整数
unsigned char, [0, 256),　signed charと同じサイズ。負の数は無い。
--------------------------------------------------------

第二部第二章標準ヘッダ <limit.h> には、
--------------------------------------------------------
CHAR_BIT
#define CHAR_BIT <#if 式 ≧ 8>
このマクロは、char 型のデータオブジェクトを表現するのに使われているビット数の最大値と置き換わる。
--------------------------------------------------------
とある。

後半は >>514 とは異なり、byte ではなく、char となっている。

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

type punning について、このスレで議論されていた union の場合は、「適合コード」の例とされている：

https://www.jpcert.or.jp/m/sc-rules/c-exp39-c.html

適合コード
以下のコード例では、オブジェクトの有効な型と互換性のある型を持つ union 型を使用している。

union {
short a[2];
int i;
} u;

u.a[0]=0x1111;
u.a[1]=0x1111;

u.i = 0x22222222;

printf("%x %x\n", u.a[0], u.a[1]);
このコード例では確実に "2222 2222" と出力される。

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

union による type punning は、C99やC11では大丈夫になったのではないか。
最後に代入したメンバ以外のメンバからの読み出しは、合法になったようだが。
よく読んでないので分からん:

https://stackoverflow.com/questions/11639947/is-type-punning-through-a-union-unspecified-in-c99-and-has-it-become-specified

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

>>517
Finally, one of the changes from C90 to C99 was to remove any restriction on accessing one member of a union when the last store was to a different one.
The rationale was that the behaviour would then depend on the representations of the values.
Since this point is often misunderstood, it might well be worth making it clear in the Standard.

[...]

To address the issue about "type punning", attach a new footnote 78a to the words "named member" in 6.5.2.3#3: 78a
If the member used to access the contents of a union object is not the same as the member last used to store a value in the object,
the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called "type punning").
This might be a trap representation.

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

>>515
日本語訳が間違ってる可能性もあるな

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

>>514
頑なに仕様書読まないのはなぜなのか

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/03(火) 22:12:33.33

>>520
仕様書が間違ってると思ってる (>>508) からじゃね。

**デフォルトの名無しさん** · 2020/03/04(水) 00:45:53.15

C++は間違っているからな
間違いで間違いを正すことはできな
い

**デフォルトの名無しさん** · 2020/03/04(水) 01:36:12.37

>>515 も仕様書だと思うのだが。

**デフォルトの名無しさん** · 2020/03/04(水) 08:18:37.27

それに基づいて作られた製品があればの話だな

**デフォルトの名無しさん** · 2020/03/04(水) 09:01:59.59

まあc++の仕様を完全に守ってる実装なんて一つもないしな。
それ確かめるのに工数かかるってどうなん？とは思う。

**デフォルトの名無しさん** · 2020/03/04(水) 09:56:46.98

>>523
それは解説書

**デフォルトの名無しさん** · 2020/03/04(水) 10:55:23.42

仕様を説明していても仕様書かどうかとは別な話だな

**デフォルトの名無しさん** · 2020/03/04(水) 12:41:56.62

>>526
実際には、あれは普通の解説書ではなく、コンパイラを実装する人が重宝するようなバッカス記法や決定性オートマトンなどを使って仕様がかなり厳密に書かれた特殊な本。

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/04(水) 13:50:02.87

>>515
古い C では違ったのかもしれないと思って
念のために C89 も確認してみたけどそのときから >>506 と同じ文言になってるぞ。
C (の公式な仕様) では最初からバイトとは char の大きさのことと結論していい。

K&R 第二版の日本語訳の付録Bだとバイトとは書いていない。
あくまでも要約だから省略したのかもしれないし、
前書きには「予備版 (ドラフトのこと？) が出ていたので早く出せた」という意味のことが書いてあるので、
仕様の決定稿が出る前の一時期にはバイトとは記述してなかった (それを元に本にした) 可能性はあるのかもね。

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/04(水) 13:54:01.41

C/C++ の仕様が信用ならんなと思うのは欠陥報告 (Defect Report) の存在だな。
仕様書に書いてないことの確認がとれていても仕様にないとは言い切れない。
把握できるわけないだろ！

**デフォルトの名無しさん** · 2020/03/04(水) 14:10:16.09

公文書だかんな
はい発表しましたよ、周知義務よろしく
↑
こういう体質なのは今さら驚いても始まらん

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/04(水) 14:57:19.24

公文書なら著作権法による保護が及ばないのでそれはそれで利点があるんだけどな。

実際には ISO は民間組織だし、正式な規格票はクソ高価すぎる。
私はドラフトと cpprefjp しか見てないんだけど、買った人いる？

**デフォルトの名無しさん** · 2020/03/04(水) 16:25:27.01

VS2019 の limits.h のコメントはこうなっている :
#define CHAR_BIT 8 // number of bits in a char

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/04(水) 16:43:02.53

そうか。

**デフォルトの名無しさん** · 2020/03/04(水) 16:43:03.91

VSの想定環境では正しいし何の問題もないな

**デフォルトの名無しさん** · 2020/03/04(水) 16:58:40.94

CHAR_BIT なのに本当に「number of bits in a byte」が厳密定義なら、何らかの説明が欲しい所ではある。

ただ、C言語では、charは言語が扱える整数の「最小単位(?)」などと書かれている文書を見たことがある。
だとすれば、Cに高級アセンブラの地位を期待する需要が有る以上、charのbit数がbyteと一致する必要は必ずあるとは思う。
総合的に考えれば、C言語においては、char=byte でなくてはならず、もはやbyteも絶対に8BITでなければならないので
char、byteがいずれも8bit
であることは事実上、必須である。

**デフォルトの名無しさん** · 2020/03/04(水) 17:05:12.53

Wikipediaの「整数型」のところで、C言語では、何があろうとsizeof(char)は必ず1になると決められており、たとえ16BITワード単位のアーキテクチャでも、CHAR_BIT は 16になるが、sizeof(char)は必ず1になるのだそうだ。
一方、sizeof(X)は、Xの「バイト数」だとされているわけだけど、はっきりいってこんな状況では総合的に考えて、charを8BIT以外には出来ない。

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/04(水) 17:14:44.63

>>536
Rationale の 6.5.3.4 に記述がある。
http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf

sizeof(char) は 1 を返す。
たとえこの単位が 36bit 幅であっても。
C 用語の「バイト」はストレージの最小単位であることを意味する。

**デフォルトの名無しさん** · 2020/03/04(水) 17:16:32.37

>>536
>C言語では、charは言語が扱える整数の「最小単位(?)」
は、>>506 の以下の部分にも書いてあるようだ。
CHAR_BIT とは、
「bit-field以外で最小のオブジェクトのbit数(byte)」
だと：

>C11 だと 5.2.4.2.1 の CHAR_BIT の説明のところに
>> - number of bits for smallest object that is not a bit-field (byte)

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/04(水) 17:18:06.36

ポインタを作れる単位を最小単位にするのは理に適ってるんじゃないの。

**デフォルトの名無しさん** · 2020/03/04(水) 17:20:06.24

「bit-field以外のオブジェクトの最小単位」
なわけだから、ポインタが指しうるアドレスの最小単位でもあるわけだ。
言葉が変かも知れないが。

**デフォルトの名無しさん** · 2020/03/04(水) 17:35:08.28

気にするような環境にない奴に限ってこういうこと気にするのな。

**デフォルトの名無しさん** · 2020/03/04(水) 17:39:54.09

個人的には、ソース配布してダウンロードした人が各自勝手にコンパイルするようにするようなプログラムを書いたことが無い。
必ずバイナリレベルでテストして十分デバッグ済みだと思ってからバイナリを配布してきたから。
ソース配布文化は別世界。

**デフォルトの名無しさん** · 2020/03/04(水) 18:59:40.00

だから何だ
結局何が言いたいんだ
規格が間違ってるって言うならISOのWGに意見書出せよ
情報は歓迎だぞ

**デフォルトの名無しさん** · 2020/03/04(水) 20:23:54.51

>>537
byteは16bitになる可能性を自分で示しているじゃないか。
一体何と矛盾してるんだ？