C言語なら俺に聞け 161

2023/04/21(金) 14:05:20.18

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

C17
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4713.pdf

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

C23 最新ドラフト
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.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言語なら俺に聞け 160
https://mevius.5ch.net/test/read.cgi/tech/1672191630/

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

2023/04/24(月) 23:45:11.28

ジャンプテーブルを使うと、変数の引き渡しに手間が掛かる
構造体のポインタを渡すとか、引数を沢山渡すとかグローバル変数を使うとか
なので、switch文にして最適化でテーブルジャンプになるのを確認するのがベストかなと

2023/04/25(火) 08:47:58.80

gcc拡張機能のラベルのジャンプテーブルが速かった思い出
あれは規格に取り込むべきだと思う

2023/04/25(火) 10:23:58.24

それってどんなのだっけか
関数を配列にぶっこんだの？

2023/04/25(火) 10:35:38.43

FORTRANの算術GOTOみたいなもんかな

2023/04/25(火) 10:36:32.19

switch caseを最適化させるとジャンプテーブルになっていることはよくあるね

2023/04/25(火) 11:21:54.95

開発環境の都合で C言語しか選択できず
C++ の virtual に相当する機構をなんとか捏造しようと
構造体に関数のポインタをメンバに持つ

あと qsort のまねっこ
（具体的な比較は外に丸投げして　そういう関数がある前提でコードを書く

**デフォルトの名無しさん** (ｽﾌｯ Sd0a-8Xzj) · 2023/04/25(火) 11:33:32.92

>>31
関数内のラベルをローカル配列の初期化て入れられて
goto labelarray[status];
見たいに飛べるやつ

2023/04/25(火) 12:02:12.18

>>28 (func)(x) に対して関数型マクロ func(x) の展開は起こらないよ。

2023/04/25(火) 12:24:03.71

調べてみた
Computed gotoってやつね

int main(void)
{
void *table[] = { &&L1, &&L2 };
goto *table[1];
L1: ;
L2: ;
}

2023/04/25(火) 12:27:03.54

参考
https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html

2023/04/25(火) 12:52:44.87

お、そんなん出来るんか

2023/04/25(火) 14:07:55.49

話の流れからして

#define func(arg) hoge(arg)
みたいな関数形式マクロがいた場合、
単に void func(int a){} と書くと void hoge(int a){}に置換されて死ぬ。
回避策で void (func)(int a){} としとけば展開されないよ

ってことじゃないの？

2023/04/25(火) 14:18:02.95

確かに、そういう効果はあるね。
それが必要になる状況は思い浮かばないけども。

2023/04/25(火) 18:35:24.79

関数と同名のマクロがわざわざ定義されてるとしたらなんか事情がありそうだが

#undef func
したほうが早くね

2023/04/25(火) 18:49:03.51

#undef の後に undef する前へリカバーできるようにする機構ってコンパイラの環境依存だよね

(リカバーのための仕込み)
#undef func
　：
void func()
{
}
　：
undefのリカバー (以下 func はマクロ側)
　：

2023/04/25(火) 19:09:41.44

ひょっとして>>21って

void qsort(void *base, size_t nmemb, size_t size,
int (*compar)(const void *, const void *));

みたいな書き方のこと？
この場合はカッコなし int *compar(const void *, const void *)
だとintへのポインタを返す関数の実体ということになり
引数宣言内に関数の実体を書くなと言われてしまうだろう

2023/04/25(火) 21:38:43.47

>>26
そうやって教えないでいて唐突になんの前触れもなく使われて「これ何ですか？」って質問したら「関数ポインタも知らねえのかよ」
テック系あるある

2023/04/25(火) 21:43:41.07

>>44
いや
int (*compar)(const void);
みたいな単独のやつだよ
てか引数に関数入れるのも教えたがらないよねえ😅
ほんと勿体つけるの大好き

2023/04/25(火) 22:14:03.47

要は関数ポインタ知らなくてバカにされただけのおじさんか
const voidだもんな

2023/04/25(火) 22:18:12.16

アホすぎて笑う価値もないな

2023/04/25(火) 22:25:14.13

>>46
それじゃエラーにならない？
具体的にどんな場面で使われてるのかわからんことには説明できないな
混乱する書き方だというのは同意するが

2023/04/25(火) 22:37:41.81

ああ、それで「関数」ではなく「関数へのポインタ」が定義できるのか
関数の型をtypedefしてからやったほうがわかりやすくない？
WindowsAPIでは大体そんな形になってるから真似してるけど

宣言
typedef int COMP_FUNC(const void *, const void *);

COMP_FUNC comp_A;
COMP_FUNC comp_B;

COMP_FUNC *comp_func = comp_A;

切り替える時
comp_func = comp_B;

呼び出す時
comp_func(...);

2023/04/25(火) 22:50:45.68

typedefがめっちゃ気持ち悪い宣言だな
普通はアスタリスクつけてポインタとしてtypedefするもんだと思うよ
sizeof(COMP_FUNC)がいくつになるのか見当がつかない不気味なオブジェクトだ

2023/04/25(火) 23:29:28.69

sizeof は関数型の式に対して適用してはならないと制約されているから
関数だったときの結果は未定義で、常識的に考えればコンパイラはエラー扱いにするべきだと思うんだけど
gcc や clang だと何故かエラーにならず 1 を返すんだよな。
(警告は出るけど。)

検出が難しいはずもない (実際に警告は出せてるわけだし) のになんでこうなってんだろ。
1 でなんか便利なことある？

2023/04/26(水) 02:32:17.99

まあ、入門書は比較的難しいことを書かないほうが売れそうだけどな
でもそれを勿体つけるというのは違うかと

2023/04/26(水) 03:51:37.33

>>50
WINAPIの書き方はこうじゃない？

typedef int (WINAPI *COMP_FUNC)(const void *, const void *);
int WINAPI comp_A(const void *, const void *);
COMP_FUNC comp_func = comp_A;

2023/04/26(水) 07:41:17.76

>>51
C++だとポインタじゃない方は関数メンバの宣言にも使えて便利だったりする。

2023/04/26(水) 08:44:09.62

>>54
ポイントされた関数の呼び出しで
comp_func(ptr1, ptr2); も (*comp_func)(ptr1, ptr2); も両方通るのは何でやろね
歴史的な都合？

2023/04/26(水) 08:54:20.40

前者は関数名そのものをポインタとして使い、後者はポインタを明示的に指定することで関数ポインタとして扱う

2023/04/26(水) 09:12:09.71

>>50
定義は？

COMP_FUNC comp_A
{
//ここどうやって書くんだ
}

2023/04/26(水) 09:27:27.18

>>58
残念ながら定義には関数型 typedef は使えない。
先に typedef を使った宣言だけ書いとけば定義の不整合を検出することはできるようになる。

2023/04/26(水) 09:46:45.42

COMP_FUNC comp_A;
COMP_FUNC comp_B;

こう書かれても仮引数や返却値の型が見えないので
可読性を落としているな

2023/04/26(水) 09:48:32.91

>>48
ほんそれ

2023/04/26(水) 10:33:18.60

>>56
* をいくつ付けても通るのは有名なネタだな。

#include <stdio.h>
int main(void) {
(**********printf)("hello, world\n");
}

関数指示子 (結果が関数型であるような式) は sizeof や & の
オペランドであるときを除いて関数ポインタに (暗黙に) 型変換されるという規則があって、
普通に printf("hello, world\n"); とか書いてあるときでもこの printf は関数ポインタに変換されてる。
関数呼出しは関数に対してではなく関数ポインタに対して行われる。

関数ポインタに * を付けると関数指示子になるけどそれもやっぱり関数ポインタに変換されるので
* をいくつつけても結果は関数ポインタという変なことになる。

2023/04/26(水) 11:39:43.86

そもそもポインタに代入するときも
int a(int b)
{
return b + 1;
}

int (*f)(int) = &a;
じゃなくて
int (*f)(int) = a;
で通るからな

2023/04/26(水) 13:38:42.38

f(0); //こうできるしな

2023/04/26(水) 14:31:03.82

>>57
comp_func は関数のポインタとして宣言されてる変数っすよ

まぁ　>>62　だということで納得

2023/04/26(水) 17:00:12.69

余談だが >>62 はあくまでも C の場合の話で、
C++ では名前解決の話が合わさって複雑になってる。
関数呼出しのときに関数名を括弧で囲むかどうかで結果が変わってしまう場合がある。
https://wandbox.org/permlink/MO8NWeVmjoLTLly6

C のコードを C++ に持っていくことはそれなりにあることなので
変な書き方をしてると組み合わせの妙で引っかかることもあるかもね。

2023/04/26(水) 20:23:11.35

正直どうでもいい
遠い昔Z80のニモニックでJP (HL)と書くけど本来はJP HLとなるはずじゃないかなと思ってたけどそれと同じｗ

2023/04/26(水) 20:32:10.51

まぁ普通は関数名をカッコで括ったりしないし

2023/04/26(水) 21:13:49.50

Cで関数のポインタガーとかやってる暇あったらC#のデレゲートとかラムダとか覚えた方がいいとおもった午後

2023/04/26(水) 21:41:13.75

「min」と「max」の関数形式マクロをわざわざ定義する.hがあるらしい

2023/04/27(木) 00:02:52.04

stdbool.hでも覗いてみればいい

2023/04/27(木) 05:12:28.80

>>67
コンバイラ、甘やかしてはイカン
最初から攻める気持ちが大切

2023/04/27(木) 08:37:39.22

コンバイラ？

2023/04/27(木) 09:03:22.20

コンバトラーV

2023/04/27(木) 13:43:25.58

JP (HL)って8080だとPCHLだっけ
アセンブラがとことん楽するようなニモニックだったな…

2023/05/01(月) 16:24:43.62

関数の引数リストの中で新たな構造体を定義するってことってできないの？
void func(struct X{int a;} b){
... something ...
}
みたいに？
構文上は可能だと思うんだけどどうなんですか？

**デフォルトの名無しさん** (ｽﾌｯ Sdbf-oZQI) · 2023/05/01(月) 18:21:57.14

構造体が使われる場所より前で定義する必要がある

2023/05/01(月) 19:09:18.47

>>47
いみもなく勿体つけるオジサン
「関数ポインタは難しいから後でやろうね～オマジナイだよ～」

2023/05/01(月) 19:15:34.08

>>53
それで後々になって質問すると
>>47,48みたいのが湧くでしょ

2023/05/01(月) 19:29:42.98

未だに初っ端からコンソールにハローワールド表示させるとこから教えてるんだろうね勿体つけオジサンたちは

2023/05/01(月) 19:36:49.71

勿体つけオジサンたちはChatGTPで「C言語で関数名に（）付けるのって何ですか？」って聞いてみればいいよ
機械以下のゴミw

2023/05/01(月) 19:44:56.10

医者から処方された薬は指示通り飲まないとだめだぞ

2023/05/01(月) 20:12:14.98

配列に対してポインタでアクセスするとか、単純な者だと絵に描けば大体理解出来るが
構造体内のポインタ変数やら、さらに配列かして行くと、記述もすんなりとできなくなるし
ましてや別人が書いたソースで、それらが一体何をアクセスしているのか理解するのは大変だ

2023/05/01(月) 20:21:43.22

>>76
返り値のほうならなぜかgccでいけた
まあ型推論がないC言語じゃあ役に立たないんだけど

// main.c
struct {int a;} func();
int main(){
printf("%d\n", func());
}

// other.c
int func(){ return 42;}

2023/05/02(火) 02:30:44.97

void func(struct {int a;} b){
b.a = 10;
printf("%d\n", b.a);
}

tccでもこれ通るな

2023/05/02(火) 11:04:32.32

>>76
私が知る限りにおいて文法上は正しい。
しかし X の有効範囲 (スコープ) は関数内だけなので
関数の外で struct X に対応する値を生成できず、
まともな方法では適切な実引数を与えることができない。

内容が同じ構造体は「適合」するし引数が適合する関数も適合するはずなので
強引にキャストして呼出しても言語仕様に反しないと思うのだけど
適合の概念をちゃんと理解できてる自信はない……

void func(struct X{int a;} b){}

int main(void) {
struct X{int a;} b = {1};
// このキャストはたぶんアリだと思うけど自信はない
void (*f)(struct X) = (void(*)(struct X))func;
f(b);
}

2023/05/02(火) 20:11:42.15

>>76
素直に最初に構造体をtypedef しとけば楽だと思うんですが
文法上で言えばstruct Xとだけ書いといて後でstruct Xの中身を定義しても正しい
もちろんそれでは関数スタックのサイズを計算できないのでエラーになるだろうが

2023/05/03(水) 14:42:04.19

Cは
struct Hoge {int a;} b;
と
struct {int a;} b;
を区別しない

2023/05/03(水) 15:45:19.73

>>88
名前の有無が違うし、変数名を変えて並べれば違う型になるし、明らかに違うと思うんだけど
何をもって「区別しない」なんて言うのか。

2023/05/03(水) 18:10:57.61

>>86
「内容が同じ構造体は「適合」する」について確認すると策定中の C23 から
内容に加えてタグ名まで同じ場合に限り適合する（compatible になる）ように変更されるようで、
現時点では正しくない模様。
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3037.pdf

2023/05/04(木) 00:37:13.28

>>90
厳格な方向に改定してんのね。
今までが緩すぎたからしょうがないね。

2023/05/04(木) 01:26:39.82

>>91
あ、ごめん書き方が悪かった。
これまではタグ及び内容が同じでも適合しなかったところ、 C23 から適合するようになるという話。
有効になるプログラムが増えるので、どちらかというと緩くなる変更。

2023/05/04(木) 04:12:02.40

急に凄くレベル低い話して申し訳ないんだけど
#include <stdio.h>

int main()
{
int a[101] = {};
a[0] = 2;
a[1] = 3;

for (int i = 4; i < 1000; i++) {
int r = 1, j;
for (j = 0; j <= 100 && a[j] != 0; j++) {
if ((i % a[j]) == 0) {
r = 0;
break;
}
}
printf("%d %d %d %d %d \n", i, j, a[j], i % a[j], r);
if (r)
a[j + 1] = i;
}
for (int i = 0; i < 100; i++)
printf("%d ", a[i]);
}
なんでこれ上手く動かないんだろう

2023/05/04(木) 05:17:57.46

このスレいつもレベル低いから大丈夫でしょ
上手く動かない？そもそもそのコードはどう動いて欲しいのか読み取れないんだよな
日頃から入出力を意識して書けって言われてない？まるで実践できてないからダメか

2023/05/04(木) 07:37:53.19

>>93
二つ目の for ループから抜ける条件の一つが「a[j]がゼロ」なのに、そのループから抜けた直後で i % a[j] とかやってて、jが2のときにa[2]が0でループから抜けるから、ゼロ除算で落ちる

それとこっちは直接の原因ではないけど、int a[101]と宣言すると a[0]～a[100]までしかアクセスできないのにa[102]までアクセスする可能性があるようなコードになってるのもダメだな

2023/05/04(木) 08:36:39.17

とりあえず初期化するとき

int a[101] = {0,1,2};
と書いたほうが楽じゃん
ちなみに初期値がない部分は0になる

後はめんどくさいから明日読むわ

2023/05/04(木) 08:46:33.13

間違えた
int a[101] = {1,2};
か

ちなみに int a[101] = {};
ではまったく初期化されないからこのプログラムでは[0][1]以外のところには0ではなく不定値が入ってるのでうまく動かないのはそれなんじゃね

int a[101] = {0};
と書いておけば省略した部分もすべての要素が0で初期化されるよ

2023/05/04(木) 09:36:07.29

>>93
i　と　j 　ってわかりづらいから　j は　k に置き換えて言うけど

i=4　のとき k=0 で　4%2 となり割り切れるため、何もせずに次
i=5 のとき　k=2 で　a[k]==0 なので k　のループを抜ける（このときk==2でa[2])
抜けた後のif (r) a[k + 1] = i;　で　a[3] = 5 になっていて　a[2]　は 0 のまま
で0除算でドボン

まずはif (r) a[k + 1] = i;　ではなく　if (r) a[k] = i;　だね

2023/05/04(木) 09:58:25.07

>>93
それとこれって素数を見つけるプログラムと思うけど、　1000までの間に163個あるっぽい
a　の要素数はそれ以上必要
（0除算している部分のprintfがデバッグ用のように、デバッグで100までに制限しているのかもしれないけど）

一応言っておくと0除算でドボンは本質とはちょっと違うからね
if (r)　a[j] = i;
printf("%d %d %d %d %d \n", i, j, a[j], i % a[j], r);
とa[j] への代入とデバッグ用のprintfの位置を入れ替えれば0除算は起きないから

2023/05/04(木) 10:19:34.63

>>95-99
丁寧な解説、ありがとうございます。

>>95,99
printfの中で0で割ってる可能性に気づいてなかったです。
a[k + 1]に代入しておかしくなってたので、原因を突き止めようとしたら
新しいバグを作ってしまっていました。

>>97
私の使ってるコンパイラだとどれでも
int a[101] = {};
でなぜか全部0が入ります。そんなものかと思って通してました。

2023/05/04(木) 11:22:57.44

初期化は自動変数と静的変数で変わるんでしょ？

2023/05/04(木) 12:22:57.41

右辺のない変数宣言だけのパターンでは変わってくるけど
静的だろうが自動だろうが　初期化の = { } は省略部以降すべて0 →　全部0フィル　でしょ

2023/05/04(木) 12:26:03.41

初期化って必ず初期値を設定するものとばかり思ってた

2023/05/04(木) 12:29:51.46

配列を「={};」で初期化したときの挙動は全要素が0埋めされるとC言語規格で決まってる

2023/05/04(木) 12:50:52.53

C17 までは初期化子が 0 個の状況は規定されていない。
一個以上が必要。 0 個を許容するとしたら処理系の拡張。

C23 からは >>102 の説明で正しい。

2023/05/05(金) 01:44:39.83

むかしニコ動で動画上げたらそのこと教えてくれた人いたな
今でも覚えてるわ

2023/05/08(月) 08:20:55.10

なので全省略せずに = { 0 }; と書くことは多いね

2023/05/10(水) 14:54:20.05

規制解除テスト

2023/05/12(金) 07:37:29.65

https://ideone.com/Kj806d

うちの環境(tcc)だと
ビット操作の実行時間: 0.634000秒
一時変数の利用の実行時間: 0.444000秒
ポインタの利用の実行時間: 0.471000秒
になるんですね、最適化が弱いにしても完全に想像と逆の結果になって驚いてる

2023/05/12(金) 08:42:01.03

ポインタのそれ交換できてるか？

2023/05/12(金) 08:58:12.44

CPU の性質も考慮する必要がある。
ビット演算はメモリのロード/ストアとは並列化できない分が効いて遅くなるんじゃないかと思う。
間接参照があればその分だけ遅くなるのも自然だし、想像通りだろ。

2023/05/12(金) 08:58:57.96

gcc(-O2)で見てみたら核の部分はswap_bitsが6命令、swap_tempが4命令になってるね

swap_bits:
.LFB0:
.cfi_startproc
endbr64
cmpq %rsi, %rdi
je .L1
movl (%rdi), %eax
xorl (%rsi), %eax
movl %eax, (%rdi)
xorl (%rsi), %eax
movl %eax, (%rsi)
xorl %eax, (%rdi)
.L1:
ret
.cfi_endproc
swap_temp:
.LFB1:
.cfi_startproc
endbr64
cmpq %rsi, %rdi
je .L4
movl (%rdi), %eax
movl (%rsi), %edx
movl %edx, (%rdi)
movl %eax, (%rsi)
.L4:
ret
.cfi_endproc

2023/05/12(金) 22:24:54.99

ビット演算はそりゃ遅いだろ
読んで演算して書く
よりも
読んで書く
のほうが早いに決まってるじゃん

2023/05/12(金) 23:57:42.36

ビット演算バージョンの特徴は一時的な格納場所が不要なところにある。
レジスタに空きが無いときにメモリに退避するよりはビット演算のほうが
マシということはありうると思う。

素朴なアーキテクチャだとメモリの読み書きが (レジスタと比べて) だいぶん遅かったり
レジスタの数が少なかったりするし。

色々な条件が絡み合うので「決まってる」とまでは言い切れない。

2023/05/13(土) 07:20:30.86

この件の場合は
関数の形でメモリから読んで書くことは確定だからそれ以上の最適化は不可能なので決まってるのだ

2023/05/13(土) 12:31:34.66

大昔の技術
今使うやつはアホ

ビット演算の方が有意に速い事なんか無いよ

2023/05/13(土) 13:31:03.33

論理演算はマシン語1命令だろw

2023/05/13(土) 14:34:03.15

std::swap使えばマシン語のxchgを使ってくれそうな気がするけどね
xchg使うのが最速だろう
Cにはstd::swapに相当するもんが無いな

2023/05/13(土) 15:37:18.91

>>117
movだけなら演算ポートを使わないで済む

>>118
マシン語のxchgは非常に遅い

2023/05/13(土) 18:27:17.14

>>117
初心者が陥りやすい錯覚だな
「何もしない(NOPのことではない)」よりも速い命令はないのだ

2023/05/13(土) 18:39:48.47

>>117
やめとけ
言ってわかる相手じゃない

何もかも機械がやってくれるから
自分の頭で考える必要はないって手合いだぞ

2023/05/13(土) 18:43:02.66

×自分の頭で考える必要はない
○アホが工夫すると遅くなる

2023/05/13(土) 18:46:13.79

今では通用しない技術を偉そうに語る
老害の典型
==>はちみつ

2023/05/13(土) 18:50:59.33

身に覚えのあるやつがファビョってるね
ん～いい返事だ

2023/05/13(土) 22:00:35.83

>>119
遅いってのは、レジスタを余計に1つ消費する方法よりも更にデメリットが有るぐらい遅いのか？

2023/05/13(土) 22:53:11.07

最適化されてもmovより遅くならない程度で決して速くなることはない
おそらくもっと複雑な処理の途中でレジスタが全て使用中の場合にレジスタをスタック等に退避することなく値を交換するテクニックとして使われたら速くなるのかもしれんが
こんなシンプルなコードでは起きないだろう

2023/05/13(土) 23:18:57.76

xorスワップは昔クヌースのメモリを使わないGCのマーク&スイープ手法だかで多用されてた気がする
当時はこれが神が作りしコードかあみたいに感動しかなかった

2023/05/13(土) 23:46:50.93

>>126
普通のコードだとレジスタは常に足りてないだろ
ベンチマーク的なコードは本当の速度を表してないな
Benchmarks gameとかそれぐらい複雑なコードを複数動かしてやっと分かるもんだろうね

2023/05/13(土) 23:49:44.86

>>125
現代的な CPU だと直接的に使われるレジスタのほかに内部にはもっと多くのレジスタがあって
見かけ上はレジスタを余計に消費していても実際には一時的に割り当てられるレジスタなことがある。
いわるゆる「機械語」も CPU 内部ではさらに分解されてよりよい命令列に置き換えられるので
同じ機械語でも文脈によって違うことをしてる。
複雑すぎて詳細な挙動を事前に予測するのは無理。
xchg が存在するからには有用な場面もあるんだろうとは思うが、
結局のところは実際にやってみないとよくわからん。