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/02/20(木) 23:28:24.92

>>399
定義が間違えているなら、正しい定義を示さないと

2020/02/21(金) 04:53:44.92

>>400
誰も間違えてるなんて言ってないし、一つ上のレスすら見てないのか？w

2020/02/21(金) 07:42:26.05

>>396
マルチプロセッサでプリエンプティブはどっちだと思う？
当たり前だがTCASはユニでもマルチでも動くんだが
それでもTSSは並列なのか並行なのかって気になるのか？
どっちでもいいって主張には賛成しかねるな

>>398
「複数のユーザー」、「複数の利用者」と至る所に書いてあるね
ダム端末は確かに昔のことだが並行か並列かという話には関係ない

「頭がおかしい」、「老害」、「知ったか」
どうも前スレあたりから変なのが常駐してるようだな
うっかり構わないように気をつけなきゃ

2020/02/21(金) 08:05:59.84

パンじゃないご飯だ

2020/02/21(金) 10:36:09.68

「頭がおかしい」、「老害」、「知ったか」

どうでも良いが、これを連呼したい奴が常住しているようだ

2020/02/21(金) 11:37:48.20

頭がおかしい知ったかのクルクルパーの老害ですが、呼びましたか？

2020/02/21(金) 12:23:48.46

>>402
> ダム端末は確かに昔のことだが並行か並列かという話には関係ない
だからその定義だと関係ないとしても、TSSの定義はそれだけじゃないでしょ
話の流れから見てダム端末とかチャネルとか言い出す方が狭すぎって話な

> どうも前スレあたりから変なのが常駐してるようだな
自己紹介乙w

2020/02/21(金) 12:35:39.58

おまいらスレタイ

2020/02/21(金) 18:13:41.02

С言語

2020/02/21(金) 18:18:26.35

C言語は「頭がおかしい」、「老害」、「知ったか」　な人が使う言語

であってますか？

2020/02/21(金) 19:15:01.45

クルクルパーもよろしく

2020/02/21(金) 19:31:48.99

8ビットCPUや16ビットでもリアルモードな頃は、
自己書換プログラム作ったりして楽しかったが
今は出来ないのでつまらない？出来ましたっけ？

2020/02/21(金) 19:34:44.69

>>404
> 「頭がおかしい」、「老害」、「知ったか」
> どうでも良いが、これを連呼したい奴が常住しているようだ

>>409
> C言語は「頭がおかしい」、「老害」、「知ったか」　な人が使う言語
> であってますか？

わざわざ自己紹介ですか？

2020/02/21(金) 19:43:30.51

>>411
できるよ
キャッシュやプリフェッチキューとかも考えないといけないしOSによってはページの属性を変更したり色々手続きが面倒だけど

2020/02/21(金) 19:55:49.81

>>402
俺は使い分けない派だよ

2020/02/21(金) 20:12:45.02

並行に動作できるよう作ってあれば並列に動かしたって平気だよ
ダイジョブダイジョブ

2020/02/21(金) 20:31:11.36

>>411
ほとんどのCPUは出来る

2020/02/21(金) 21:10:22.71

効いてる効いてるｗ

2020/03/24(火) 03:27:56.26

こんなマクロ M1 M2 を作りたい。
int a[] = M1( test1, M2(a), M2(b), M2(c));
　↓
int a[] = { sizeof(test1), offsetof(test1, a), offsetof(test1, b), offsetof(test1, c), -1 };

とりあえずこう定義したけどやっぱりだめだった。M2 の st が展開されない。
#define M1(st, ...) { sizeof(st), __VA_ARGS__, -1 }
#define M2(f) offsetof(st, f)

うまい方法があったら教えてください。
コンパイラは gcc です。
M1 に構造体名を与えたら M2 でもその構造体名を展開したいというのが要点です。

2020/03/24(火) 08:54:15.16

M1(test1, a, b, c)
としてM1内でM2使うしかないのでは。

2020/03/28(土) 14:30:29.95

int ***A;
の意味は何ですか。

2020/03/28(土) 17:59:16.47

int ***型（intへのポインタへのポインタへのポインタ）の変数Aの宣言

2020/03/28(土) 19:07:09.14

*は幾つまで羅列できますか。
int ******how

2020/03/28(土) 19:10:30.31

シロナガスクジラにもでかすぎる釣り針だなｗ

2020/03/28(土) 19:12:30.55

Qiitaだったかブログだったかに実験結果あるよ。

2020/03/28(土) 19:48:29.31

言語仕様的には何個でもいいんじゃね。
でもただ * を並べるだけじゃなく、const や volatile なんかと組み合わせるとここに居る連中でも頭を悩ませることになりそうだ。

2020/03/28(土) 19:54:41.66

三個くらいなら良いが、そんなに並べてプログラマがついて行けるんか？

2020/03/28(土) 20:38:40.13

前に見かけたこの記事がある
たった4000個ほどしか付けられないらしい

printfに4285個アスタリスクをつけるとclang++が死ぬ - Qiita
ttps://qiita.com/kaityo256/items/84d8ba352009e3a0fe42

2020/03/28(土) 21:33:45.25

>>425
原理上は無限でも問題ないし言語の規格上の上限があるかは知らないけど、コンパイラの実装上は何らかの上限があるだろうね。

2020/03/28(土) 22:23:34.67

規格では下限は決まっている

2020/03/28(土) 22:27:31.37

(***printf) ないし (*printf) ってどういう意味になるのかな？
関数ポインタに * を付けても同じ型で同じ値の関数ポインタになるということ？
少なくとも値は * を何個付けても変わらないみたいだけど。

2020/03/28(土) 22:37:27.60

ちなみに &printf も同じ値だね。
ちなみに関数ポインタ変数 p を使った場合、&p は変数p 自体のアドレスになったけど、p も *p も関数自体のアドレスで同じ値になる。
ちょっとややこしいかも。

2020/03/29(日) 04:08:50.01

メモリを[アドレス](データ)で表すと
int ***A;は
[Aアドレス](アドレス1) -> [アドレス1](アドレス2) -> [アドレス2](アドレス3)
-> [アドレス3](int データ)
を指していることかな。

2020/03/29(日) 06:29:54.31

int (*fp)(void); /* fp: 引数なし, intを返す関数を指すポインタ */
と定義された関数ポインタ fp を経由して関数を呼び出す際に、
fp() でも (*fp)() でも同じ意味だよ、と規格で決めた結果として、
ならば (**fp) も (***fp) も…同じだよね、てことになったのかな。

アドレス演算子の方も
fp = some_func;
fp = &some_func;
どちらの書き方でも fp 経由で同じ関数を呼び出せる、という点で合理的か。
他の解釈をしても意味ないし。

おかげで
fp = &**&***&some_func;
などと書くこともできる。これは無意味で過剰な一般化の類にも思えるけど。
fp = &&some_func;
とは書けない模様。
この辺の挙動はコンパイラによって違うのかも。

2020/03/29(日) 07:46:51.93

sizeof fp //ok
sizeof *fp //error

fp = &some_func; //ok
fp = &fp; //error

2020/03/29(日) 16:07:52.64

int a = (*&*&*&*&*&*&*&f)();
こんなんもありか？

2020/03/29(日) 16:10:44.92

++--++--++--++--a;

2020/03/30(月) 06:39:21.96

>>436
Cだとコンパイルエラーだね。
最右の--で増やされた値に左隣の++を作用させられない。

C++だと動作する。
「前置の++/--演算子が左辺値を返す」だっけ。

**437** (ﾜｯﾁｮｲ 697b-scJV) · 2020/03/30(月) 07:50:54.17

誤: 最右の--で増やされた値
正: 最右の--で減らされた値

増減を間違えたわ。

2020/04/01(水) 21:03:42.40

そろそろ変数名、関数名にUTF-8を使えるようにしてもいいと思う。
多分楽しくなるよ。

2020/04/01(水) 22:34:39.51

void ぴゅう太(void) {
漢字();
漢字();
鉄矢();
鉄矢();
}

2020/04/02(木) 06:56:27.27

全角空白やアラビア語などを駆使したioccc作品が楽しみだな

2020/04/02(木) 07:54:18.84

古老おらんか
cmakeてのはいつ頃流行ったシロモノなんだ?

2020/04/02(木) 08:47:09.83

よく知らんが５年前には普通に使ってた

2020/04/02(木) 12:01:47.47

i286時代の16bitC言語ってfarポインタ経由でも64KBごとにしか連続メモリアクセスできなかったんでしょうか？

2020/04/02(木) 12:17:36.01

透過的にはアクセスは出来なかったと思う

2020/04/02(木) 12:24:50.02

連続アクセスをどのレベルで言ってるのかによるけどHugeポインタ使えば見かけ上は連続アクセスできる
ただしかなり遅い

2020/04/02(木) 12:29:05.08

FARポインタって値としてはリニアアドレスで、メモリアクセス時に内部的にセグメントとオフセットに分けてるだけじゃなかっけ？
ポインタを ++ しながらメモリアクセスして 64KB 越えても問題無いんじゃね？
memcpy みたいのが内部的に rep 使った lods や stos を使ってるなら、ライブラリとして 64KB 単位に区切ってるんじゃないのかな。

2020/04/02(木) 12:31:00.60

あれ、おれの言ってるのって hugeポインタだっけ？

2020/04/02(木) 12:39:01.60

もう使ってないし､使いたくもないし、思い出したくもないｗ

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
例えばどんな感じですか？