C言語なら俺に聞け 154

2020/01/14(火) 19:32:30.16

!extend:checked:vvvvv:1000:512
(新スレ立ての際上記コマンドを2行書き込んでください)
C言語の話題のみ取り扱います C++の話題はC++スレへ
質問には最低限の情報(ソース/コンパイラ/OS)を付ける
数行で収まらないソースは以下を適当に使ってURLを晒す
https://paiza.io/
https://ideone.com/
http://codepad.org/

C11
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf

C99
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
http://kikakurui.com/x3/X3010-2003-01.html

C FAQ 日本語訳
http://www.kouno.jp/home/c_faq/

JPCERT C コーディングスタンダード
https://www.jpcert.or.jp/sc-rules/

※前スレ
C言語なら俺に聞け 153
https://mevius.5ch.net/test/read.cgi/tech/1566050562/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2020/04/02(木) 12:40:53.46

組み込み小規模は今でもメモリモデルやらFARポインタやらがある

2020/04/02(木) 13:48:38.35

i80286のバグを利用してリアルモードでありながら1MB超のメモリを使うなんてテクあったな

2020/04/02(木) 14:07:43.96

>>446
連続アクセスはポインタを ++ でインクリメントしながらループするレベルで言っています
Hugeポインタというものもあったんですね、知りませんでした
これを使うとポインタを ++ する度にセグメントレジスタを更新するので遅いが64KB以上のアクセスができるって事ですよね

farポインタはポインタを ++ してもセグメントレジスタは更新されず、早いけど64KB以上のアクセスはできないって事でしょうか？
あれ、もしそうなら例えば0x0EFFF0を指すfarポインタで ++ しながらメモリアクセスした場合
16バイト以上は0xE0000に戻ってしまい0x0F0000以降のメモリにアクセスできないって事ですか？

2020/04/02(木) 17:09:56.05

「正規化マクロ」なんてのもあった記憶がある。
オフセット部の上位ビットをセグメント部に移して、
オフセット部の値を 0-15 に制限する。

適当なタイミングで「正規化」することで
64KBを越える範囲を連続的にアクセスできるようになる。
いわゆる「透過的」ではないけれど。

2020/04/02(木) 18:29:53.16

>>442
90年代前半？

2020/04/02(木) 18:32:26.76

>>452
もちろんそのセグメントで扱えるブロックの範囲の先頭に戻る
そういうときはセグメントレジスタの方の値を増やさないと無理

2020/04/02(木) 18:35:21.60

>>452
誤解されそうなので補足だけど
>0x0EFFF0を指すfarポインタで ++ しながらメモリアクセスした場合
セグメントレジスタ 0x0EFFF
ポインタ 0x000F
なら 0x0EFFFF にアクセス出来るし
セグメントレジスタ 0x0EFFF
ポインタ 0x0010
なら 0x0F0000 にアクセス出来る

2020/04/02(木) 18:58:03.66

>>456 >>453
ああなるほど、セグメントレジスタは16倍してオフセットに加算されるんですね
勘違いして認識していました、ありがとうございます
そうなるとfarポインタでも基本的には64KBまでならそのままアクセス可能そうですね

◆QZaw55cn4c (ﾜｯﾁｮｲ e3aa-5LkK) · 2020/04/02(木) 21:31:59.26

>>446
＞Hugeポインタ
速度ペナリティも高かったし、なによりもバグっているとの報告がちらほら…

◆QZaw55cn4c (ﾜｯﾁｮｲ e3aa-5LkK) · 2020/04/02(木) 21:33:11.59

>>447
オフセットがあふれてもセグメント部分はインクリメントしない、したがって 64 KB を超えて連続アクセスはできない

◆QZaw55cn4c (ﾜｯﾁｮｲ e3aa-5LkK) · 2020/04/02(木) 21:33:30.14

>>448
huge はバグっていた

2020/04/02(木) 21:41:01.11

30年前にタイムスリップしたかと思った

2020/04/02(木) 22:01:10.37

Hugeがバグってた？
本当？

2020/04/03(金) 01:16:56.77

>>457
16ビットと一言で言ってるけど、x86の場合リアルモードとプロテクトモードでセグメントの扱いは全く異なるから注意
16倍して足すだけなのは前者のとき(DOSとか)
Windows3.1は後者

2020/04/03(金) 07:13:39.26

>>462
そういう処理系があったって話でしょ
まあ処理系のバグだーって言う奴の99%は自分のコードがバグってるんだけどな（俺調べ）

2020/04/03(金) 07:42:16.55

そうそう
どうせコードがバグってるのをコンパイラのバグだと騒いでるんだと思って聞いてみた

2020/04/03(金) 08:17:02.15

まあQZは思い込みが激しいし話半分に聞いておけばいいな

◆QZaw55cn4c (ﾜｯﾁｮｲ e3aa-5LkK) · 2020/04/03(金) 20:17:25.73

>>462
中島信行氏の記事にそういうのがありました

>>464
huge ポインタがあったのはたしか MS だけだったかと

2020/04/03(金) 20:59:00.91

>>464
条件が成立してるはずなのにどうしても走らないコードがあり、コンパイラの最適化のバグで処理が消えたと思い最適化のスイッチをいろいろいじり、
それでもだめでコンパイラ自体のバグを疑い吐かせたアセンブラソースに処理コードが吐かれてないことを確認して、
ほれ見たことかコンパイラが悪い！と報告を上げた後でコメントの */ が抜けてることを発見した俺には敵うまい。

2020/04/04(土) 00:47:19.29

私はいくつかコンパイラのバグを見つけたけどね
見つけた時は発生する最小形にしてから報告

コンパイラのバグだとさわぐヤツの99%は自分のバグ
ってのは同意

2020/04/04(土) 00:50:16.07

>>467
> huge ポインタがあったのはたしか MS だけだったかと
Turbo Cですらサポートされてるんだが…
https://www.drdobbs.com/using-large-arrays-in-turbo-c/184402289

2020/04/04(土) 00:55:46.93

Internal Error って言うのを見たことはある

2020/04/04(土) 08:44:49.54

99%もそんなアホいるのか？
コンパイラのバグを疑った場合まず最小の再現コード作るだろ
で、バグレポに条件と現象を書くわけだが
自分が悪い場合はそこで必ず気付くことになる

2020/04/04(土) 09:28:47.06

>コンパイラのバグだとさわぐ
× こういう風に書いたのですがｘｘのコンパイラなら問題ないのにｘｘｘの方だと誤作が(ry
〇 xxxつかったら動かねぇ！！ソースに間違いは無い！！クソコンパイラ！！謝罪と賠（ｒｙ

2020/04/04(土) 10:12:08.70

>>472
> コンパイラのバグを疑った場合まず最小の再現コード作るだろ
> で、バグレポに条件と現象を書くわけだが
そんなこともせずに騒いでる奴が多いって話だろ

2020/04/04(土) 12:47:58.45

今は分からないが、20年くらい昔だと
あまりにも複雑なソースを食わせると時々発狂してたな

2020/04/04(土) 13:15:20.63

>>468
負けた。君に勝ちを譲ろう。

2020/04/04(土) 13:15:46.68

30年前くらいじゃないか？
あまりにも複雑なソースを書くのが悪い
っていう時代

今でもあまりに複雑なソースは悪
別の意味で

2020/04/04(土) 13:29:50.17

10年くらい前でもマクロのネストが多いとかでInternalエラー吐く処理系はあったよ
本来ちゃんとエラーチェックして適切なエラーメッセージ出すべきなんだろうけどほとんどありえないような状況にどこまで対応すべきかって話はなかなか難しいものがある
まあそれと処理系のバグとは別の話だが

2020/04/04(土) 14:50:27.38

>>477
そんなん、やろうとしていること次第だろ
複雑になっちまうものはそうするしかない
意地悪しているわけでもないコードをけなすのは
自分の品位を損なう愚行だ

2020/04/04(土) 15:13:09.29

>>479
複雑って言うのはスパゲティコードというより循環的複雑度みたいな話だと思うよ
複雑度が上がるなら適切に関数化するとかで避けるとか

2020/04/04(土) 15:16:24.42

なんか全然、噛み合ってないね

2020/04/04(土) 15:55:02.64

｢あまりに複雑な｣
って時点で悪

やろうとしてることが複雑でも
記述を複雑にする必要は無い

2020/04/04(土) 19:49:17.44

なんだ、主観論か

2020/04/05(日) 00:53:15.82

cでコンパイラがゲロる複雑に成るって三項演算子をネストするくらいだろ
c++はテンプレートでわりあい簡単に混乱を引き出せるけどCのメタ構築機能はゴミみたいなもんだし

2020/04/05(日) 05:06:11.76

３項がどう結合するかを理解してないやつがオレ文法と違うって騒ぐのは
駅前で不特定多数を叱りつけている危ないオヤジと同じ

2020/04/05(日) 07:26:24.26

人間にとっての複雑とコンパイラにとっての複雑化はまったく違う

演算子のネストなんて3項じゃなきゃ普通にやってることで
コンパイラにとっては普通のこと

3項演算子の結合は特殊なので
人間にとっては複雑なのは間違いないけど

2020/04/05(日) 07:31:27.17

3項演算子の優先度は
良くある演算子の優先度表を見るだけじゃ仕様がわからない

>>485もその辺を理解してるかどうか

2020/04/05(日) 09:05:29.09

>>487
> 3項演算子の優先度は
> 良くある演算子の優先度表を見るだけじゃ仕様がわからない
意味不明、普通にわかるだろ
https://ja.cppreference.com/w/c/language/operator_precedence

2020/04/05(日) 09:20:09.55

>>488
その表でもわざわざ欄外に注記している通り、演算子の順位だけを見ても分からないということだろう

**デフォルトの名無しさん** (JP 0H93-3bw/) · 2020/04/05(日) 11:43:40.11

4Dエンジン
ttp://x0000.net/topic.aspx?id=3677-0

ある強力なFor関数
ttp://x0000.net/topic.aspx?id=3630-0

SQLライブラリ
ttp://x0000.net/topic.aspx?id=3675-0

matrixのライブラリ
ttp://x0000.net/topic.aspx?id=3711-0

2020/04/05(日) 13:47:36.92

C/C++仕様が違うんだよね三項演算子

2020/04/05(日) 14:48:53.25

三項演算子は優先順位よりも結合性の方がわからなくなる

2020/04/05(日) 14:56:50.54

A ? B : C;
A ? B ? D : E : C ? F : G;
(A ? B ? D : E : C) ? F : G;
A ? B ? D : E : (C ? F : G);

◆QZaw55cn4c (ﾜｯﾁｮｲ e3aa-5LkK) · 2020/04/05(日) 15:03:25.55

>>492
私は
A1 ? B1 : A2 ? B2 : A3 ? B3 : C3
みたいにお気楽に後ろに後ろに結合するのがいいです

2020/04/05(日) 15:03:37.61

コンパイラにとって複雑というのは、構文木が深くなる、とどのつまり項の多い長い文なんじゃない？
昔のコンピュータはメモリが足りなかったから深い木は扱えなかったってことでしょ。

2020/04/05(日) 15:58:31.05

>>494
人間には右につなげる方が見やすいのかも知れないが
コンパイラ的にあいまいさが無いのは左(内側？)に入れていく方だと思う

Pythonのはさらに結合の優先度が判りにくい気がする(慣れてないだけかも知れない)

2020/04/05(日) 19:35:26.18

>>494
それは時と場合によるのでは？

2020/04/05(日) 19:36:57.26

>>493
改行を工夫すると見やすくなる

2020/04/07(火) 02:00:59.45

>>498
例えばどんな感じですか？

2020/04/07(火) 07:11:26.19

? を if と同じように改行 & インデントすればいい

A ?
    B ? D : E :
    C ? F : G;

A
    ? B ? D : E
    : C ? F : G;

2020/04/07(火) 07:15:13.75

A ?
. . B ? D : E :
. . C ? F : G;

A
. . ? B ? D : E
. . : C ? F : G;

2020/04/07(火) 07:20:31.07

>>494の場合は

A1 ? B1 :
A2 ? B2 :
A3 ? B3 : C3

A1 ? B1
: A2 ? B2
: A3 ? B3
: C3

2020/04/07(火) 07:39:02.54

なぜ素直にif文を使わないんだ

2020/04/07(火) 08:25:22.73

当然 if や switch caseやテーブルと使い分ける
? : が適した場合に使う

2020/04/07(火) 08:57:58.17

某「省略の美学」とか言うのを売りにしてる言語に憧れてるんだろ。

2020/04/07(火) 12:46:52.50

この世には括弧というものがあってだな・・・

2020/04/07(火) 12:55:18.38

三項演算子で処理を書くな
ただの代入にわざわざif文を使うな

2020/04/07(火) 17:39:24.91

代入の右辺だけ書いただけ
処理でこんな書き方をするのは特殊な場合(競技とか)

2020/04/07(火) 23:16:28.11

Kotlinは思い切って三項演算子なくした代わりにifを式にしちゃったよ。
他の言語からのパクリだとは思うが、val a = if (x == y) b else c のような書き方ができる。

◆QZaw55cn4c (ﾜｯﾁｮｲ c2aa-zNgl) · 2020/04/08(水) 00:50:21.46

>>509
lisp とか haskell とか、関数型全般はそうやりますよね…

2020/04/08(水) 02:14:53.71

>>509
その記述
int a = x == y ? b : c;
に比べて何かメリットあるの？

2020/04/08(水) 03:26:20.58

>>511
ダメと言われている三項演算子を使ってません！と言えることかなw

一つあるとしたら、ネストさせたときに if ... else if ... else if ... else とできることか。
式の中に文のような表現が入る気持ち悪さがあるから、三項演算子の方がまだましな気もするが。

2020/04/08(水) 08:02:03.15

ダメといわれている？
初耳

else if は >>494 や >>502 が同じ事をやってて
こっちの方が見やすいと思う

2020/04/08(水) 09:37:01.78

>>513
どこかのコーディング規約や一部の教条主義者の間で言われてるみたいだよ。(>>512前段はそれを揶揄したつもり。)
俺自身は三項演算子は分かりやすさを損なわない範囲で使うのは大好きだし、>>502の前者の書き方はよく使う。

2020/04/08(水) 12:55:24.71

gotoダメとか3項演算子ダメとか

2020/04/08(水) 15:40:20.61

関数呼び出しするのに、引数ではなくグローバル変数でやり取りする奴見たことある
ナイフ一本持ってジャングルの中を探検する気分になれた

2020/04/08(水) 16:05:35.74

gotoは例外処理とか使いどころもあるのに、大人はみんなダメと言う

2020/04/08(水) 16:06:38.12

>>516
スタック節約とかのバッドノウハウとしてはよく見る

2020/04/08(水) 16:12:43.67

>>516
シングルトンのクラスだと思えばそんなに変じゃないんじゃね？

2020/04/08(水) 16:36:56.26

>>519
シングルトンならグローバル構造体にして関数を介して読むべきだな

2020/04/08(水) 17:43:28.57

>>516
よくやります。君もやりたまえ。

2020/04/08(水) 18:06:51.24

関数仕様(プロトタイプ)を変えたくないとか
関数をたすさん経由するので変更が多いとか
少しでもパフォーマンスをあげたいとか
少しでもリソースをけちりたいとか

理由はいろいろとある
綺麗さよりもそういった事が重要であれば使うこともある

2020/04/08(水) 18:20:05.30

パフォーマンス改善の仕事してるけどパフォーマンスのためにグローバル変数使うとか聞いたことないわ

2020/04/08(水) 19:27:06.81

井の中の蛙宣言しても意味無くない？

2020/04/08(水) 20:24:48.12

>>520
別に構造体にする必要は無いじゃん。
しいて言えば、引数でたらい回しにするときこそ構造体が便利で、そういうやり方になるとシングルトンというより this を明示的にやり取りする普通のオブジェクトみたいなもんじゃね。
グローバル変数でシングルトン的に実装するなら、グローバル変数を全部 static にしてソース内にスコープを絞る感じじゃね。

2020/04/08(水) 20:33:22.56

>>523
キャッシュにヒットしやすい配置に並べやすいとか、
引数渡しでは必要なスタックに引数を積み上げるコストを節約できるとか、
戻り値を複数貰いたい場合に余計なポインタや構造体を使う必要が無いとか、
「どの程度」はともかくいろいろありそうだけど。

2020/04/08(水) 21:53:33.85

>>516
組み込みだとよくあるよ。その方がデバッグしやすいんだと。

2020/04/09(木) 02:17:55.56

ICEのメモリダンプでリアルタイムに状態の変化を追跡するのに変数のアドレスがスタックを動き回られては確認しづらいので
グローバル変数で寿命を永続化してアドレスマップを固定アドレス化することはよくある

2020/04/09(木) 07:57:04.28

errnoの悪口？

2020/04/09(木) 11:01:14.49

C言語10年ぐらいやってるけどいまだにエラー機構の正解が見えない
errno使おうかと思ってた時期もあるけど、けっきょく構造体使ってエラーハンドリングしちゃう

2020/04/09(木) 11:29:30.64

>>530
グローバル変数とlongjmp

2020/04/09(木) 11:41:05.77

jmp_bufはグローバルにしちゃダメだよ

2020/04/09(木) 12:28:29.74

>>531
例外みたいに？
そういえばマクロでtry文再現してるライブラリがあったな

2020/04/09(木) 18:27:54.57

>>532
何故に？

2020/04/09(木) 21:06:08.39

>>534
例外ハンドラの階層を構成できなくなるからだ

2020/04/09(木) 21:26:59.30

>>535
そういうケース限定の話ということね

2020/04/10(金) 06:06:54.66

限定ってそれ以外に何を考えているんだ？

2020/04/10(金) 09:24:51.46

全てのケースで例外は階層化しないといけないって言う病気にでも罹患してるのか？
最終手段としてトップレベルに抜けるだけにしか使わないとか普通にやると思うけど

2020/04/10(金) 10:17:13.27

ああexit使うと怒られるから形を変えるってやつね

2020/04/10(金) 11:09:12.87

例外があったらプロセス終了ってw
別にライブラリが呼び出し元に戻る直前の手段として longjmp する場合、jmp_buf はライブラリのソース内の static なグローバル変数でもいいわけで。
グローバルにするかローカルにするかなんてその時の作りに応じて選べばいいだけで、グローバルじゃダメなんて何のルールだよって話なだけだろ。

2020/04/10(金) 12:20:25.35

別にルールとか言ってねえぜ、勘違いすんなよ
飛ばされては困る処理はない方がレアケースで
だからグローバルはお奨めしないと助言したんだよ

2020/04/10(金) 13:03:17.75

例外発生時は自分自身にリセット要求出して割り込み禁止して無限ループ

2020/04/10(金) 13:17:24.64

>>539
随分低レベルな考え方だなw
通常のエラー処理は戻り値とかでやるけどロジックエラー等の回復不可能なエラーはlongjmpでトップレベルまで戻ってログ吐いて止まるなりリスタートなりするとかだよ

>>541
> 飛ばされては困る処理はない方がレアケースで
階層化の話はどうしたんだよw

2020/04/10(金) 13:35:44.69

long long a;
int b;
a >>= 8 * b;
‾‾‾‾‾演算のオーバーフロー
4バイトの値に演算子*を使用し、結果を8バイトの値にキャストしています。
オーバーフローを避けるため、演算子*を呼び出す前に値を幅の広い型にキャストしてください。

シフト演算でも右辺値は左辺値の型にキャストされるのですか？

2020/04/10(金) 15:49:55.13

>>543
例外はむしろ回復可能なエラーへの対策が主要な用途だぞ
ゲロって止まるって、おまえエラーとバグを混同してるか？

俺は別に階層化の話から逸脱はしてねえぞ
そう思いたいのか？

2020/04/10(金) 16:27:16.96

>>545
> 例外はむしろ回復可能なエラーへの対策が主要な用途だぞ
お前の流儀が主要とか言われても困る

> ゲロって止まるって、おまえエラーとバグを混同してるか？
文章理解力なさすぎだろw
>> 通常のエラー処理は戻り値とかでやるけど

> 俺は別に階層化の話から逸脱はしてねえぞ
飛ばされて困る処理が常に階層化されてると言うのか？

> そう思いたいのか？
お前が（あえてかどうかは知らんけど）書いてないから指摘しただけ

2020/04/10(金) 17:07:36.93

>>544
32bit環境の gcc では特に何も言われないな。

2020/04/10(金) 17:53:11.95

>>546
俺個人の流儀ではない

エラー処理には返却値を使う方法と例外を使う方法がある
この点はおまえ完全に間違って憶えているようだな

飛ばされて困る処理を確実に実行させるために
階層化とリスローをするんだよ

おまえ何もわかっちゃいねえな
買いかぶってた

2020/04/10(金) 18:07:17.86

ごちゃごちゃ言ってるのを読む気にもならんが、結局グローバルでもいいんだろ？
階層組みたきゃそれができるように実装すりゃいいだけだよな？
的はずれなこと書くと無駄に長くなるってことが分かったな。
はいおしまい