C言語なら俺に聞け 163

2024/07/16(火) 22:43:54.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言語なら俺に聞け 162
https://mevius.5ch.net/test/read.cgi/tech/1698653580/

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

2024/07/16(火) 23:09:40.55

警備員[Lv.4][新芽] (ﾜｯﾁｮｲ 5a73-fQmy) · 2024/07/17(水) 00:38:03.50

"甲乙丙丁"[1];

2024/07/17(水) 02:16:43.37

C23 最新ドラフト
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf

2024/07/19(金) 12:09:58.52

C23 最新ドラフト
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf

2024/08/13(火) 10:33:10.70

C99以降のC言語では、main関数が正常に終了した場合、
明示的にreturn 0;を記述しなくても、コンパイラが自動的にreturn 0;を
挿入することが規定されています。
これにより、main関数の最後にreturn文を省略することが可能になりました。

これまじ？
いや省略できるのは知ってたけど
書かなくても言語仕様的に正しいってことなのでは

2024/08/13(火) 10:54:13.55

>>6
> 省略できる

これまじ？ってやってみたら省略できた。知らんかった。

2024/08/13(火) 11:02:03.46

C++の方は最初からそうじゃなかったっけ？

2024/08/13(火) 11:04:04.36

ところで、main以外はどうなんだろう
mainだけ特別って事なのかな？OSとも絡むし

2024/08/13(火) 11:58:17.89

>>9
retunr 0; が補われるルールは main だけの特別扱いだけど……。

関連する変な規則として C では関数の返却値の型が void ではないときに return せずに } に到達、かつ、関数の呼び出し元が値を使おうとするのは未定義ということになってる。
逆に言えば } に到達するだけなら OK ってことね。
C++ だと関数の返却値の型が void でないときに return せずに } に到達するだけで駄目という違いがある。

2024/08/13(火) 20:38:38.66

>>9
値を返さない関数ならreturnは省略できる
値を返す関数だと戻り値が不定になる
(多分コンパイルでwarningが出るか最近のではerrorになるだろうな)
そのくらい一度も試したことないのか？

2024/08/14(水) 08:45:20.95

CPUが最後に処理したアキュムレータの内容が
戻り値として有効になってるケースが多い
違う実装があったら教えてくれ

2024/08/14(水) 09:29:38.29

戻さないで自動的に挿入されるのならvoidでいいやん

2024/08/14(水) 16:14:28.35

>>12
CPUでも最適化レベルでも変わるのでその情報は無意味だ
素直にvoidにしとけばいいじゃん

2024/08/17(土) 12:40:14.00

>>12
じゃあお前に教えるために
これからそういうの作ろう

2024/08/17(土) 17:19:02.88

>>12
最適化が絡むとなんでも起こる。
GCC でやってみた。
https://godbolt.org/z/rzoEqdYWz

インライン化と合わさったときはおそらく
「なんでもいいなら事前に適当な定数 (この場合はゼロ) に置き換えてええやろ」ということが起こってる。
インライン化を抑止したらそのときに入ってたでたらめな値になる。

2024/08/18(日) 12:47:05.86

CGCのサイクル
https://www.cgcjapan.co.jp/recruit/images/system/cgc-system.jpg

2024/08/19(月) 14:50:35.14

CCG
https://dic.pixiv.net/a/CCG

2024/08/19(月) 15:05:46.71

アキュムレータって呼び名、いかにも電卓っぽい

2024/08/26(月) 18:48:30.29

ヘッダファイルちゃんとincludeしようよ。

2024/08/26(月) 19:32:21.98

ヘッダーファイルインクルードする1行だけのプログラム見たことがある

#include /dev/tty

2024/08/27(火) 00:49:35.29

それヘッダファイルじゃないです

2024/08/27(火) 08:24:35.00

エラー: #include は "FILENAME" または <FILENAME> が必要です

2024/08/27(火) 14:09:22.45

<>を入力すると消えるブラウザというか掲示板も流行ったなHTMLは糞だわ

2024/08/27(火) 17:58:59.59

大抵最初の開発者は誰かが修正してくれるだろうと適当な仕様で設計して、
その後引き継いだ開発者はなにか意図があるのだろうと思ってそのまま維持していくという悪循環・・・。

2024/08/28(水) 01:09:19.85

>>25
あるある過ぎる

2024/08/28(水) 01:32:44.54

ちち、どっかいけ

2024/08/28(水) 01:35:08.84

ごばくした、ごめん

2024/08/28(水) 09:35:19.18

アーニャにはここはまだ早い

2024/09/02(月) 15:52:36.13

RustがCより速くなるベンチマークは見たことがない

Nim2.0のORCは明示的にオブジェクトプールを使ったプログラミングが必要ですが
ベンチマークがCより２倍以上速くなって、特にハードなリアルタイムシステム向け
のチューニングもできるようになってるみたい
https://zenn.dev/dum...icles/af2b2b9f8fd890

Nim2.0がCより２倍以上速くなって、しかもORCでメモリ安全も担保されているなら
Rustを使う意味がなくなると思うのですが、このベンチマークは本当なのでしょうか？

NimはCのソースコード吐けるからから、Nimの手動メモリ管理はCの手動メモリ管理と
同じとして、Nim2.0のORCで明示的にオブジェクトプールを使ったプログラミングと
比較した場合のベンチマークが2倍以上速くなってるからCより速いと言ってる
https://github.com/Araq/fosdem2020

人間がCの手動メモリ管理したプログラムだと限界があるNimのムーブセマンティクスの
アルゴリズムでメモリの最適化をしてるから、人間では到底太刀打ちできない事を証明
した論文があるオブジェクトプール版のNimから生成したCのコードは人間には書けない

Nim2.0のムーブセマンティクスの本当に優れた最適化とORCで明示的にオブジェクトプールでプログラミングすることによって、人間がCの手動メモリ管理したベンチマークより2倍以上速くできる
https://zenn.dev/dumblepy/articles/af2b2b9f8fd890

2024/09/02(月) 22:08:58.52

Rustを褒めて自尊心保つやつの次はNim版が出てきたのか

2024/09/02(月) 23:12:40.71

Nim推しは以前から変なやつ多かったから

2024/09/02(月) 23:28:27.10

Nim言語の良し悪しは分からんが、メモリ管理に関しては理想的だわ
ムーブ後のオブジェクトにアクセスするとRustだとコンパイルエラーで面倒な事になるけど、Nimは参照カウントを使って解決するので少し遅くなるだけだ
そっちの方が絶対良い
気になる場合は後で直せる

2024/09/03(火) 18:51:27.81

>>33
コンパイルエラー？

2024/09/04(水) 01:03:52.03

>>34
だからなんだ？
Rustでムーブ後のオブジェクトにアクセスしてみろよ

2024/09/04(水) 09:34:28.92

>>33
どこにコンパイル時期にメモリの不正アクセス検知できるコンパイラーがあるんだよ
便利すぎないか

2024/09/04(水) 09:42:59.71

>>36
ムーブ(所有権の移動)の概念知らない奴かよw

2024/09/04(水) 11:20:54.96

時代に取り残されたじじい

2024/09/04(水) 11:26:12.60

今どきのヤングはどの辺を走っているのかな？

2024/09/05(木) 00:07:48.49

RefCellのborrowとかborrow_mutがCより速い訳がないだろ

2024/09/05(木) 06:20:13.32

アセンブラ使ったことない子供たちにはわからんのだろ

2024/09/05(木) 08:53:17.49

Aiの時代にこんなレトロ言語に夢中になってる場合でもないだろ

2024/09/05(木) 09:42:51.26

ペイントソフト溢れた時代にエクセルで描いて絶賛される時代。

2024/09/05(木) 13:27:55.60

AIなんて究極的には予備知識なしで使えるようになるもんだろ
いま必死で呪文を覚えてる奴らには気の毒だがｗ
プログラムの学習はそれとは逆だぞ

2024/09/05(木) 13:41:12.34

AIにはアセンブラかCで書かせた方が効率がいいじゃん

2024/09/05(木) 20:45:06.75

今はアニメもCGで作る時代だけど、だからデッサン力なんて不要と言ってるのに近いなw

2024/09/06(金) 02:12:25.16

AIなら直接機械語書けそうだけど最低限人間がコードを読めるようにするためにCで出力するのが流行りそう

2024/09/06(金) 17:06:00.74

もはやプログラマはAIにどう質問するかだけが求められてる時代
ビックデータが前提なのはわかってるけどchatAIと画像AIはマジでオーパーツだわとても0と1だけで実現されてる技術と思えん・・・

2024/09/06(金) 17:30:18.67

ここはAIの質問スレになる予定です

2024/09/06(金) 17:59:38.15

>>48
Cやアセンブラを知らなかったらコンピューター自体が魔法に思えるんだろうなｗ

2024/09/06(金) 18:14:44.45

プログラム上での比較が、未だに変数2つの比較（if（A=B）とか）しかイメージ出来ないので
AIのアルゴリズムどころか、2つのサイズの違う画像比較ってのさえどうやるのか検討もつかん・・・。

2024/09/06(金) 18:37:17.18

3Blue1BrownJapanのディープラーニング解説動画
https://www.youtube.com/watch?v=tc8RTtwvd5U
現在chapter6まで和訳されてる（本家英語版は7が出た）

2024/09/06(金) 21:13:32.20

>>51
引き算してその絶対値が一定以内だったら同じとみなす
if(abs(A-B)<C){…
それぐらいならわかるだろ？

2024/09/06(金) 21:19:53.07

点でしか見れない人に面を理解させる手法・・・

2024/09/06(金) 21:46:42.59

この世界もほぼ陽子と中性子と電子だけで出来てるのにこれだけ複雑なんだから0と1だけで複雑な演算出来ても不思議ではない

2024/09/06(金) 21:53:29.16

ようこちゃんとでんこちゃんは知っているけど
中性子って子は知らない

2024/09/06(金) 22:09:25.96

光子ちゃんも忘れないであげて

2024/09/07(土) 00:47:09.38

0と1だけじゃないけどな
その他に位(くらい)という概念がある
これによって無限の数を表現できる
むしろ位の概念によって数が表現されている
それさえ有れば記号なんて何でもいい

2024/09/07(土) 20:51:59.47

どこかの国だか村では両手の指の数以上を表現する言葉がないって話をどこかで・・・。

2024/09/07(土) 22:06:43.98

ムカデは100進数で数えている

2024/09/08(日) 00:25:53.15

>>59
位の概念が無いから10までしか数えられない
位を考慮すると両手で1023まで数えられる

2024/09/08(日) 00:30:46.43

指を曲げる伸ばすの２通りとすると1023だが、指を完全に曲げる、伸ばす、半分まで伸ばす(曲げる)の3通りとすると3^10-1=59,048まで表現できるなw

2024/09/08(日) 07:38:58.99

>>60
ヒトを含めた四肢類は4進法なの?

2024/09/08(日) 10:08:59.05

>>61-62
人差し指と薬指を伸ばして、かつ中指と小指を曲げるのは難易度がやや高いぜ。
（親指を伸ばせば『グワシ』）

2024/09/08(日) 10:25:56.18

グワシは古語

2024/09/08(日) 15:41:04.82

とりあえず、他人の投稿で言ってもいない単語や解釈を勝手に加えてマウント取ろうとするのはどうかと思うぞ。

2024/09/08(日) 23:23:27.00

問題はギャグとしてつまらないという点だ

2024/09/09(月) 17:06:32.51

lvalueに関してエラーが出るんだけど、どうしてこれがだめなのかわからないです

#include <stdio.h>

int main()
{
char s[] = "hoge";
char t[100];
while (*t++ = *s++)
;
printf("%s", t);
}

2024/09/09(月) 17:17:50.19

>>68
　char *p = s;
　char *q = t;
　while (*q++ = *p++)

こう書けば通る。何故かはちょっと考えて ;

2024/09/09(月) 17:19:13.64

>>68
s の型は char[5] 、 t の型は char[100] だというのはわかる？
だけど式に出てくる配列は原則として配列の先頭要素を指すポインタ (この場合に型でいえば char*) に型変換される。
変換後に出てくるポインタは rvalue なのでインクリメントの対象に出来ない。

rvalue ってのは式の評価をする間に一時的に生まれて評価が終わったら消えるものなので
仮にインクリメント出来たとしても何にも使えない。

配列が勝手にポインタに変換されるっていうのが変則的で分かり難いポイントだけど
これは C を使ってたら避けようがない。

2024/09/09(月) 18:22:38.82

ポインタと同じ表記が使えるだけでポインタに変換されるわけではないぞ老害

2024/09/09(月) 18:25:50.23

　char *s = "hoge";
　char t[100];
　int i = 0;
　while (*(t+i) = *s++)
　　i++;

ｓを配列ではなく、ポインタに変える、
ｔもポインタにしたいところだが、格納先確保が目的なら
先頭アドレスからのオフセット指定で格納する様に変更

2024/09/09(月) 18:30:55.08

それなら while (*(t+i) = *(s+i)) って書くかな

2024/09/09(月) 18:36:50.90

s[]、t[100]と書いたとき、ｓやｔはメモリー上の特定の位置を指す
ラベルのようなものなので書き換える事は出来ない。ポインタ定数とも言う。
一方ポインタ変数は、任意のアドレスを指す変数、変更も操作できる
constとか、突っ込まんでください

2024/09/09(月) 18:57:03.60

>>71
規格には「型変換する」と明瞭に書いてあって変換しないと解釈できる余地はない。

68 (ﾜｯﾁｮｲ fa2d-2PHd) · 2024/09/10(火) 07:06:02.36

色々教えてくれてありがとう
s[]の先頭を指すポインタ*sを++で進めることができちゃったら
s[0]もズレちゃうのでだめだってことだよね
そりゃだめだわ

2024/09/10(火) 07:45:50.17

s[], t[100]; って宣言したなら、s[idx], t[idx] って使おうよ

2024/09/10(火) 08:09:53.27

そこはこだわらんでもいいだろ

警備員[Lv.5][新芽] (ﾜｯﾁｮｲ f969-ztXh) · 2024/09/10(火) 09:09:59.70

sやtは constということでもないのか

2024/09/10(火) 10:14:17.88

立て札は移動禁止です

2024/09/10(火) 13:19:09.36

>sやtは const
constっていつからあったか知らんけど
constない頃からsもtも*pや*qとは扱いが違ったんじゃね

2024/09/10(火) 14:04:37.40

lvalue の概念は K&R 1st の頃からあったよ。
lvalue という用語はちょっとどうなの……と思うけど。
Rust だと place と呼んでるみたいだね。

2024/09/10(火) 21:10:52.20

お前は変な事ばかり言ってるからもう引っ込んどけよ

2024/09/10(火) 21:22:40.00

ポインタそのものを変えないやつと
指す先を変えないやつの書き方で
未だに迷うっていう

2024/09/10(火) 21:35:00.77

キーワードを並べる順序で意味が変わるのは迷うけど
順序をどうならべても良い場合もそれはそれでびっくりする。

int const long foo;

みたいに変数を宣言して良い。
まあそんなことをするやつはいないと思うけど。

2024/09/10(火) 22:53:26.23

consr char*は本当はchar const*と書くべきなんだよね
これでもコンパイルは通って同じ結果になる
読む時は右から読めばいい
pointer to const char
これだと指す先がconstなのが分かりやすい
ポインター自体をconstにするには
char* constとして、同じく右からconst pointer to charと読む
両方constは
char const* const
となるけど、最初のconstは左に書けるので
const char* const
とも書ける
これが分かれば迷う事は無くなる

2024/09/11(水) 01:20:44.10

それ前橋氏のポインタ完全制覇で知った

2024/09/11(水) 08:00:07.84

>>81
アセンブラにして考えるとわかりやすい

char s[] = "hoge";
アセンブラの表現↓
s:
　　　.db "hoge¥0"

char *s = "hoge";
アセンブラの表現↓
s_org:
　　　.db "hoge¥0"
s:
　　　.dw s_org

上の場合書き換えようにもsには実体がない
アドレス定義ラベルでしかない

*ただし完全に最適化されると下も上と同じになる
　　　

警備員[Lv.1][新芽] (ﾜｯﾁｮｲ 1ea1-ztXh) · 2024/09/11(水) 09:16:47.77

ここでいう sには実体がない、とはどういうことですか?

2024/09/11(水) 09:19:23.27

大元の質問が >>68 なので低レイヤからの説明はあまり筋が良くないと思う。
エラーメッセージの意味を読み取れるようにならないから。

2024/09/11(水) 09:30:46.32

8ビットCPUのメモリ保護されてない頃だと
配列どころか、プログラムコードも書換できました笑

2024/09/11(水) 09:49:35.14

> sには実体がない、とはどういうことですか?
変数エリアに書き込まれていない数値、データ。
プログラム上で要求された時にコンパイル時や関数によってその都度作られる仕様・・・かな？しらんけど。

>91
>プログラムコードも書換できました
それはむしろ”技術”扱いだったな。
サブルーチンでジャンプ先やIOポートを書き換えて・・・て。
昔はCPU等のバグ利用がテクニックだったけど、今じゃバグの温床、セキュリティホール扱いだね。

2024/09/11(水) 15:02:12.18

こんだけいて>>77くらいしかまともな回答者がいないとかひどいなあ

2024/09/11(水) 15:25:16.11

そんなのこだわっても結局関数の引数で配列型では渡せないんだからその程度は受け入れて慣れたほうがいい

2024/09/11(水) 15:58:54.52

ここは、「聞け」とはあるが、「回答する」とは書いていない

2024/09/11(水) 16:44:23.62

こっちが自然だろ
t[100]を*(t+idx)なんてやる方が何の拘りだよ

2024/09/11(水) 16:55:25.58

その程度どっちでもいい

警備員[Lv.4][新芽] (ﾜｯﾁｮｲ 8afb-ztXh) · 2024/09/11(水) 20:45:08.11

配列は外部リンケージのときも注意が必要なんだよね
あまりそういう使い方しないから、すぐにはピンとこないや

2024/09/11(水) 22:04:51.93

>>93
別にまともでもない
配列で定義してポインタで操作できるのがCの柔軟性だから
idxにこだわると簡単な操作を複雑にしかねない

2024/09/11(水) 23:11:00.81

＞　while (*(t+i) = *s++)

これは、

＞　while (*t++ = *s++)
;これがエラーになるのは何故かと言う質問から始まったからです

t++がエラーで、t+iなら大丈夫が理解できれば解決だと思う
ポインタの理解というのは壁にはなりますが、
乗り越えれば意外と簡単です、がんばれ！

警備員[Lv.7][新芽] (ﾜｯﾁｮｲ f931-ztXh) · 2024/09/12(木) 00:58:15.86

>>92 ありがとうございました(sには実態がない)

gcc -S test.c
で .s を出力して眺めてみると、そのような感じになっていました
最適化と、AT&Tのオペランドが逆なのに慣れず読みにくかったですが

"hoge" は「実体」が .data に置かれ、実行時にスタックにコピーされるのかと想像してましたが、実装がどうあれ、スタッフ上に "hoge" を置くための元を実体というのは違うと思いました

実際、"hoge" は .db でアロケートされず、4字は 32ビットの数値定数とされ、スタックに即値で転記されていました(実行時に生成されていました)

# とても伝わりにくいと思いますが…

2024/09/12(木) 08:54:43.60

誰も説明してなかったことに気づいた。
E1[E2] が (*((E1)+(E2))) と等価であるというルールがある。

2024/09/12(木) 21:59:57.92

それいにしえからのバカ発見器なんだが2024年になってもまだ動いてるとはC言語おそるべし

警備員[Lv.3][新芽] (ﾜｯﾁｮｲ b68a-ztXh) · 2024/09/12(木) 23:41:05.77

次の方どうぞ

2024/09/12(木) 23:43:09.62

>>103
その自由度があるからC++でhtbl["key"]の様な事が出来る
Cじゃ意味ない仕様だけど、禁止する必要も無かろう

2024/09/13(金) 08:23:17.89

>>101
"hoge"は長さちょうど32ビットだから即値でスタックに書き込むようになってるということなら
最適化によってそこまで省略されてるわけでsに実体がない件とはあまり関係ないな
最適化オフにするかもっと長い文字列で実験してみては

警備員[Lv.5][新芽] (ﾜｯﾁｮｲ 1eeb-ztXh) · 2024/09/13(金) 09:12:47.27

>>106
ありがとうございます

もう少し正確に書けばよかったのですが、4字と '\0' の2回に分けて転記していました
また、hogeを長くして(10字くらい？)試すと、やはり 4字ずつ整数にパックして即値で転記していました

もっと長大な文字列試せば、別にアロケートされたそれをコピーするコードが吐かれたかもしれませんが、>>92 の指摘通り、実体がなく実行時に生成されることを確認できたとして打ち切ってしまいました

2024/09/13(金) 10:12:57.71

C の仕様は抽象機械の動作として記述される。
抽象機械の動作をどのように実際の機械と対応させるかは自由で、見かけ上の動作が同じならどういう機械語になってもいい。
生成された機械語から言語仕様を理解しようとすべきではないよ。

低レイヤプログラミングするならどう対応付くか知る必要がある場合もあるのは否定しないけど……

2024/09/13(金) 10:23:10.52

その抽象機械の定義はしょせん後付け
c言語のソースから生成されるマシン語の想像が付くようになるのはいいこと

2024/09/13(金) 10:25:26.12

C言語ハンドコンパイラ

2024/09/13(金) 11:25:36.89

>>109
機械語の想像がつくのが不要とも悪いとも言ってないよ。
そこから言語仕様を理解しようとすべきじゃないと述べてる。
できないから。

2024/09/13(金) 11:46:29.60

所詮部外者の推測。

2024/09/13(金) 12:46:10.11

今日は患者が多いですね

2024/09/13(金) 12:53:56.59

>>111
無用な心配
Xに溢れてるクソリプと同じ

警備員[Lv.1][新芽] (ﾜｯﾁｮｲ 1e86-ztXh) · 2024/09/13(金) 13:50:08.30

>>108
ありがとうございます

そもそも >>88 で sの実体がないとはどういうことか、というのが疑問だったためで、言語の仕様(というか実装)がどうかには着目していませんでした

printf("%s\n", s); が .sではputs(s); に置き換えられていたり
そうだよな～

警備員[Lv.1][新芽] (ﾜｯﾁｮｲ 1e49-ztXh) · 2024/09/13(金) 13:59:45.58

あー、実装には注目してるのか>自分

2024/09/13(金) 14:32:38.41

この場合に限っては言語仕様としての理屈もあんまり違わんけどな。
ただ、正式な用語を知ってると細かいことを調べやすいみたいなのはあるので便利。

**デフォルトの名無しさん** (JP 0H3e-voeu) · 2024/09/13(金) 16:10:44.34

gccは配列に確保した短い文字列は最適化無しでもレジスターに載せてしまってるな
ポインター文字列は最適化してもレジスターには載らない
なので配列は配列として使った方が最適化で高速化される可能性があるという事だな

2024/09/13(金) 16:26:39.79

ポインター文字列って変な言葉だな。
この場の造語だと思うけど
char *foo = "bar";
みたいなやつのことだよね？

文字列リテラルは静的記憶域期間 (寿命はプログラムの最初から最後まで) を持つオブジェクト。
どこかにある文字列をポインタで指しているという状況。
そのどこかにある文字は他のどこかから指し示されることもありうるので簡単には消えられない。

その一方で、配列の初期化子は配列を初期化する以外に使われる可能性がない。

2024/09/13(金) 16:36:31.22

>>93
それのどこがマトモなんだよ

>>94 の言い分の方が正しい
配列型が無いんだから

2024/09/13(金) 16:38:54.03

>>96
>t[100]を*(t+idx)
t[100]を100[t]
よりはマシ

>>97
だよな

**デフォルトの名無しさん** (JP 0H3e-voeu) · 2024/09/13(金) 17:26:56.71

>>119
んなこたーない
char foo[] = "hoge";
char* bar = &foo[1]; /* 敢えてずらしてみる */
printf("bar -> %s\n", bar);
で中身は何度も参照されるぞ
gccで試してみたら敢えてずらしてポインターに代入されたとしても、レジスターに文字列を保持したままprintfに渡すというトリッキーなコードが生成されたｗ
スタックに文字列を書き込んでそのアドレスを渡してるっぽい

**デフォルトの名無しさん** (JP 0H3e-voeu) · 2024/09/13(金) 17:45:50.36

短い配列文字列をポインターに代入したらレジスターに保持する最適化を諦めるかと思ったら、そうじゃなくて意地でもレジスターに保持したまま処理を進めるgccスゲーよｗ
clangの場合はポインターも配列も常に静的に文字列を定義したものを使ってた

2024/09/13(金) 18:12:32.57

最近のCPUはレジスターに文字列格納できるんだな
何バイトくらいなら入るんだろうか

**デフォルトの名無しさん** (JP 0H3e-voeu) · 2024/09/13(金) 18:26:19.17

gccの場合だと64bitだと8バイトだから最大7文字かなと思ったらレジスターを複数使ってでも載せようとしてたｗ
取り敢えず50文字まで試したけど全部レジスタに載ってた
でもこの辺はレジスタの空き具合にもよるのか？詳しくは分からん

2024/09/13(金) 18:41:27.03

何か執念みたいなのを感じました笑

**デフォルトの名無しさん** (JP 0H3e-voeu) · 2024/09/13(金) 18:50:06.89

スマン…間違えた…orz
正確にはアセンブリコードに書かれてると言うべきだった
movabsq $3833745473465760056, %rdx
movabsq $3978425819141910832, %rax
movq %rdx, 40(%rsp)
movabsq $3544395820347831604, %rdx
movq %rdx, 56(%rsp)
↑こんな感じで文字列が直値で表現されてて、スタックに積んで使ってた
だったら静的に確保した方が速い気がするけど、やっぱりレジスターから直接使う事が有るのか？
取り敢えずコンパイラーが出力するコードに深入りしない方が良いって事は分かったｗ

2024/09/13(金) 18:59:17.17

>>122
その場合に参照されるのは foo であって、 "hoge" というリテラルではない。
"hoge" は foo を初期化する以外の用途に使われていない。

2024/09/13(金) 20:11:25.22

>>127
データセグメントに確保するよりも
コードセグメントに書いたほうがすでにキャッシュに載ってるから高速なのかもな

警備員[Lv.5][新芽] (ﾜｯﾁｮｲ 1e21-ztXh) · 2024/09/13(金) 20:41:46.32

速度の最適化か、生成されるオブジェクトの小ささかのトレードオフなんだろうね
テスト用のコードは小さいから、後者は気にせずゴリゴリやってるのかな…

2024/09/13(金) 23:38:57.27

世の中CやめてRustにしろだとか
OpenAIの新AIが競プロで上位1割のプログラマに匹敵とか言うじゃない
今更人間がCを続ける意義ってなんなんだろう

2024/09/14(土) 00:03:48.69

COBOLみたくロストテクノロジーを理解出来る貴重な人になれる

2024/09/14(土) 00:19:19.91

低レイヤに関わる資料が C を前提に書かれていたりするのは普通のことなのでたとえ C でプログラミングしなくてもある程度は身に付いてないと困ることはあるだろう。

2024/09/14(土) 00:39:08.66

>>128
初期化する以外に参照されてないってのはおかしいだろ
printfで中身が表示されてんだから
ポインター変数のbar経由で中身を参照してるけど、中身は初期化で渡された文字列そのものだ
そもそもリテラルが参照されてないという言い方もおかしい
リテラルは単なる定数の簡略表記に過ぎず、ソースコード上だけの用語だ
実行時に消えてると言いたいのか？
そんなわけない、全く消えてない

2024/09/14(土) 00:51:01.21

>>132
CobolやFortranはこれからも生き残るよ

多分

2024/09/14(土) 08:27:14.72

>>134
言ってることが意味不明。
textセグメントとかbssとかdataセグメントとか知らんの？

2024/09/14(土) 08:59:02.76

>>134
> printfで中身が表示
意味が解らん。
表示されてる中身というのは foo の中身であってリテラルじゃないだろ。

> リテラルは単なる定数の簡略表記
整数リテラルなどは右辺値だが文字列リテラルに限っては左辺値。
文字列リテラルは実行フェイズにおいてオブジェクトとしての性質を持つということ。 (抽象機械の上では。)
ただし、この文字列リテラルが型変換された結果によって生まれるポインタはアドレス定数の要件を満たす。

2024/09/14(土) 10:32:56.64

>>137
int i = 1;
printf("i -> %d\n", i);
この1は同じ様にリテラル表記以外に参照されてないというのか？

2024/09/14(土) 10:49:21.06

>>138
前述の通り整数リテラルは右辺値 (rvalue)。
文字列リテラルは例外的な存在だ。

まず、 C の用語では「オブジェクト」と「値」は違う意味を持つ。
メモリ上のビットパターンがオブジェクトで、値は式の結果だ。
(規格用語では data storage だがここではあえてカジュアルな用語で言うことにする。)

そして式の結果は lvalue と rvalue に区分される。
オブジェクトに結び付いている値が lvalue だと考えていい。
個々に規定があるので詳細は割愛するが、
式の中で変数名だとか単項 * 演算だとか [] とかがあればそれはメモリ上に存在してるのは明白だろ？
そういうのが lvalue 。

たとえば 1+3+5 みたいな式があれば途中で 4 という値が生じるが、これは「どこ」にある？
場所に結び付いておらず、式が終われば破棄されることになってる。
こういうのが rvalue 。

ちなみに lvalue も rvalue が要求される文脈では rvalue に変換される。 (メモリから値が読みだされる。)

2024/09/14(土) 12:58:36.93

>>138
このときの 1 というリテラルは (rvalue の) 1 を返す式で、その値が i にコピーされた後で寿命を終えて消滅する。
printf の引数の i で取り出される 1 は i に入っている 1 であってリテラルの 1 じゃない。
整数リテラルはあくまでも整数を返す (生成すると言ってもいいかも？) 式であって、メモリ上のどこかにあるオブジェクトというわけじゃない。

2024/09/14(土) 13:32:49.89

>>140
1は破棄されて"hoge"は破棄されないんだろ？
だから参照されてんじゃん

2024/09/14(土) 13:40:20.14

>>141
>>122 の bar が参照しているのは文字列リテラルからコピーされた配列であって文字列リテラルではない。
文字列リテラルが破棄されないこととは独立した話だよ。

2024/09/14(土) 13:43:47.04

>>142
barは配列のコピーじゃないだろ
ポインターなんだから
コピーしてるのはアドレス値だぞ

2024/09/14(土) 13:55:39.65

>>143
そのポインタが指しているという意味で参照してると言ってる。
なにを言いたいんだ？
論点は「配列の初期化子として現れる文字列リテラルは配列の初期化以外に使われる可能性がない」という話だろ。

2024/09/14(土) 14:05:45.99

＞ char foo[] = "hoge";
＞ char* bar = &foo[1]; /* 敢えてずらしてみる */

＞ bar が参照しているのは文字列リテラルからコピーされた配列であって文字列リテラルではない。

説明がよく分からないが、barは、fooではなく、どこかにコピーした別の文字列なり配列を参照していると言うことか？

2024/09/14(土) 14:20:52.41

>>145
bar はどうでもいいよ。それは要らん間接参照を入れて例としてよくわからんようになってるから
飛び飛びになってる私の書いてることをあらためてまとめると

・ char foo[] = "hoge"; といったような記述があれば "hoge" によって foo を初期化する。
・このときの文字列リテラル "hoge" は foo を初期化するだけに使われて他からアクセスされる可能性がない。
・言語規格の建前上は文字列リテラルの寿命はプログラムの最初から最後までだが……
・この場合は他からアクセスされる可能性がないから機械語レベルでは文字列リテラルは最適化で消えて (即値としてコードに埋め込んで) も問題にならない。

2024/09/14(土) 16:37:38.90

つまり
>>118 でgccが文字列を即値にする最適化の条件を推察したら
はちみつ餃子が規格の観点で説明が不適切ってぼこってるわけか？
前者の情報のほうが有益だわ

2024/09/14(土) 16:47:20.53

>>147
補足したつもりだが。
どう最適化するにしても規格に反する挙動にしてはならない (したら規格に対応しているとは名乗れない) からどうしてそれで規格に反しないのかの観点から説明した。

2024/09/14(土) 17:01:46.57

最適化でどうなるかを考えながらC書くくらいならもうアセンブリ書いたほうが良いと思う

2024/09/14(土) 17:07:34.51

>>146
はちみつは文字列リテラルがアセンブリソースの段階で"hoge"と書かれてなければ消えてると思ってんだなw
例え命令コードの即値で書かれていても消えてる訳じゃないからー！残念！
だから話が噛み合わなかったんだw
まぁ強いて言えば、最適化でデータの表現法方を変えても構わないって言えば良い

2024/09/14(土) 17:14:48.19

x = 1; ← 最適化で消えても構わない
x = 2;
最適化で消えても構わないってこういうことを言うんだよ
char foo[] = "hoge";
"hoge"は消えて良い訳ないだろw
gccは実際、命令コードに文字列を埋め込んでスタックに生成してるが、その文字列はポインター変数を使えば参照可能だ

2024/09/14(土) 17:26:48.38

>>149
それはそう。原則としては言語の理屈に従っておくのが良い。
繰り返すけど、少なくとも初心者に対して低レイヤの観点で C を説明するのは筋が悪いと思う。

2024/09/14(土) 17:33:13.32

>>151
> 参照可能だ

その時参照してるのはスタック上にある配列であって、文字列リテラルではないってのを俺は何度書けばいいんだ？
文字列リテラルは本来は「プログラムの開始から終わりまでの寿命を持つオブジェクト」としてあらねばならないのが、
実際には文字列リテラルではない形になってることを「消えてる」と表現したのは確かに微妙な表現だったかもしれないが、
有るべき場所から消えてるんだからそんくらいわかるだろ。

そもそも最初は char* foo = "hoge"; との対比で言ってたんだから。

2024/09/14(土) 18:13:05.20

はちみつ餃子の説明はたぶん、C++ の考え方が混ざっていないか
C で配列の初期化子に文字列リテラルが書けるのはあくまで文字列リテラル限定であって、それは式として扱われるのではなく、lvalue も rvalue もクソもないということだと思うが

2024/09/14(土) 18:35:19.29

>>154
初期化子の文法の一部であって式の規則の適用範囲外じゃないの？ってことだよね？
6.7.8 を見てこの場合でも式だと解釈してるけど、そういわれたらちょっと自信がないかも。

2024/09/14(土) 18:53:38.72

>>153
その配列に格納されているデータが文字列リテラルから生成された文字列(の実体)だろ
厳密に言いたいなら、文字列リテラルはコンパイル時に存在さえしてれば良いものなんだよ
何しろ「リテラル」だから
それを生存期間だの実行時の実体とごっちゃにしてるから訳分かんないことになんだよ
コンパイル時にさえ存在してれば良いという事を実行時には消えてても良いとか言っちゃってんでしょ？

2024/09/14(土) 19:03:33.67

char foo[] = { 'h', 'o', 'g', 'e', 0 };
文字列リテラルは↑のシンタックスシュガーだ
初期化子は消えても構わないのか？
初期化子が生成した文字列は参照出来ないと言うのか？

2024/09/14(土) 19:10:37.88

>>155
https://en.cppreference.com/w/c/language/array_initialization
ここ参考にしてたから文法定義の時点で式じゃないと思ってたけど、ちゃんと規格上は式としてのパースではあったね、すまない
改めて C99（でいいんだよね、6.7.8 ってことは）の draft 読んでみたけど、文字列リテラルで初期化できるのは 6.7.8.14,15 で特殊に定義された意味論であって、やっぱり式扱いじゃないんじゃないかね

2024/09/14(土) 19:58:20.45

>>154
結果的な挙動からするとどっちでも良いから書いてないだけかも。

2024/09/14(土) 20:16:47.07

皆拘らずに使っているのに言うのもあれなんだが
C言語にはC++で言う参照はありません

2024/09/14(土) 21:01:12.02

hogeは破棄されないって一人がんばってるID:0gsw2riP0を救済して差し上げたいが……自分も完全にわかってないのでできない。

2024/09/14(土) 21:04:22.62

実在するのはfoo[]だけで
文字列"hoge"は破壊どころか最初からあっても無くてもいいというのがここまでにわかったことだろ

2024/09/14(土) 22:15:49.35

配列と別に文字列もどこか別に確保しといて何の意味があるんだよ
この形で配列作る度に二倍メモリ食うことになるじゃないか

2024/09/14(土) 22:32:05.03

>>163
せやで。だから最適化の余地があるという話をしてる。

2024/09/14(土) 22:34:31.27

ここで最適化の話は混ぜない方が良い

2024/09/14(土) 23:00:09.33

>>163
clangは配列でも文字列リテラルは残ってるよ
ここって想像だけで語るアホばっかだなw
リテラルはコンパイル時のみに必要
それとは別に実行時にリテラルを実体化した値が存在する
基本的にrvalueだ
でないと当然初期化が出来ない
この値をはちみつは無視して語っている

2024/09/14(土) 23:04:40.23

はちみつはリテラルはコンパイル時にのみ必要な事と、実行時には必要な初期値(rvalue)を最適化で命令コードに埋め込む事を消えたと表現して、ごっちゃにしてるアホ
これが結論

2024/09/14(土) 23:11:36.67

リテラルは参照されないと言ってるのがその証拠
そりゃコンパイル時にのみに必要なその場でデータ構造を表現するリテラルを、実行時に参照出来る訳ないだろw
それが出来るのはコードをデータとして表現してるLisp だけだ
C++のテンプレートでも無理
C++のconstevalなら可能になった
std::formatはそれで実装可能になった
実行時には初期化の為のrvalueが絶対に存在する

2024/09/14(土) 23:13:53.14

constevalも文字列リテラルを参照可能なのはコンパイル時のみだった…
やっぱり真に実行時に文字列リテラルを参照可能なのはLisp だけだな

2024/09/14(土) 23:40:13.14

>>1 の C17 ドラフトのリンク C++17 のやつじゃん
次スレ立てるならこれに変えといて

https://web.archive.org/web/20181230041359/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf

2024/09/14(土) 23:53:27.27

>>167
起きていることは >>127 でこれ以上なく具体的に説明されてるんだから改めて厳密に表現しないと理解できないとは思わなかったんだよ。

>>168
文字列リテラルが静的記憶域期間を持つことは 6.4.5 に書かれてる。
実行フェイズに存在するオブジェクトだよ。 (最適化を抜きにして仕様通りに解釈すれば。)

配列の初期化子として現れる文字列リテラルの扱いは微妙かもという話が >>154 >>158 の指摘だが、
記憶域期間についての記述は文脈を指定せず文字列リテラル全部を対象にした記述に見える。

2024/09/15(日) 00:57:56.19

>>163
そりゃ書き換える場合があるからでしょー
一個しかなかったら関数呼ばれるたびに初期値も書き換わってしまう
なんで悩んでるのこの人？
constつけたら一個ですむだろ多分

2024/09/15(日) 01:17:55.27

>>171
> 実行フェイズに存在するオブジェクトだよ。
存在してんじゃねーかよ！
これが最適化で消えて良いかの話だよ！
gccの場合は命令コードに埋め込んでるけど、消えてる訳じゃないし、別のポインターから参照可能だ

2024/09/15(日) 01:30:47.17

>>173
配列とその初期化子として現れる文字列リテラルが別の存在だってことが俺が何度も書いてることだよ。
これがそんなに何度も何度も何度も何度も書かないと理解できないようなことか？
別のポインタは配列を指せるが、その初期化子として現れる文字列リテラルを指せるわけじゃない。

char* foo = "hoge";

のようなケースではポインタ foo は文字列リテラルを指してるということと対比しての話だぞ。

2024/09/15(日) 01:32:35.13

ちなみに「文字列リテラル」が「実行時」に存在してる訳では全くない
はちみつはそこを勘違いしてる
静的記憶期間というのはスコープの事だ
まぁエクステントと言った方が正確だが
それはコンパイラーが理解できるものだが、それと「実行時」に存在する値を結びつけてはいけないし関係無い
DLLだとしたら静的記憶期間の変数も実行時には存在しない可能性もある
スレッドローカルストレージの変数もそうだな

要するに文字列リテラルで生成されたデータは実行時には確実にアクセス可能で、消えてるなんて全くあり得ない
それをずっと言ってる

2024/09/15(日) 01:38:12.52

>>174
> 文字列リテラルを指せるわけじゃない。
はい、これが間違いの全て
文字列リテラルはコンパイラーだけが理解できる「構文」に過ぎない
それを実行時にさせないとはこれいかに？w
文字列リテラルは「実行時」には何て名前になってんだ？
配列でもないぞ
配列に代入される前のrvalueの事だ
まぁ文字列は例外的にlvalueにもなれるが、rvalueであることには違いない

2024/09/15(日) 01:45:15.62

>>171
なんかいろいろ書いたけど最終的には自分もそれで合っていると思う
実用上は正直どこで役に立つのかあまり思いつかないが、規格上どういう建て付けになってるのかはとりあえず理解できたかも
というか、実用上あんまり役に立つわけじゃないから今まで調べもしなかったというか

規格上は「リテラル」は存在せず integer/enumeration/floating/character は定数なんですね
それで定数は記憶域期間を持たない
文字列リテラルは静的記憶域期間を持つ
複合リテラルは関数本体の外か中かに応じて静的/自動記憶域期間を持つ、と

うーんでもなあ
某言語でいきなり &1 とか書けるの知ってたら別に定数にも記憶域期間持たせればいいじゃんとか思っちゃうなあ
とりあえずそうなっているというだけか

2024/09/15(日) 01:46:17.50

>>175
> 静的記憶期間というのはスコープの事

ちがう。記憶域期間はオブジェクトの寿命の区分。
6.2.4 を参照のこと。
寿命の区分が設定されている以上はオブジェクト (メモリ上のどこかにある) のこと。

> 文字列リテラルで生成されたデータは実行時には確実にアクセス可能で、消えてるなんて全くあり得ない

関数 (C のプログラムは関数の集合なので実質的にプログラムの全て) はオブジェクトではない。
私が「消える」と表現したのはこの意識があったからだが、機械語のレベルでどこかには存在するという意味ではそりゃ存在するだろう。
(同じ内容が連続する配列だったらループで書き込むような形にすることもあるかもしれない。)
配列の初期化子としての文字列リテラルは本来あるべき場所 (オブジェクト) から最適化で消えてるし、ポインタで指すことは出来ない。

2024/09/15(日) 01:53:34.48

>>177
C++ の右辺値参照も左辺値参照も左辺値なんだよね。
参照を経由したら左辺値になるなら最初からそう出来ないか？と思ったことはある。

2024/09/15(日) 01:58:39.53

>>178
> ちがう。記憶域期間はオブジェクトの寿命の区分。
だからエクステントと書いてんだろ！
もしかして理解出来なかったか？

> 配列の初期化子としての文字列リテラルは本来あるべき場所 (オブジェクト) から最適化で消えてるし
本来あるべき場所(オブジェクト)って何だよ？！
目茶苦茶だなw
これがコンパイラーと実行時に存在すべき値(rvalue)をごっちゃにした成れの果てだなw

2024/09/15(日) 02:33:43.11

初期化に使われた(文字列)リテラルが実行時にrvalueになったものに名前を付けるべきだな
これは最適化でも消えることはない(当たり前だが…)
名前がないとまたリテラルは消えるから参照出来ない野郎が発生しかねないw

2024/09/15(日) 12:24:08.15

>>174
＞char* foo = "hoge";
＞
＞のようなケースではポインタ foo は文字列リテラルを指してる

その表現が間違ってる。
fooは静的記憶域を指してるが正しい。

intptr_t *bar = 0xAABB;
この場合数値リテラルを指すなんて言わんだろ。

警備員[Lv.2][新芽] (ﾜｯﾁｮｲ 5707-/vo+) · 2024/09/15(日) 13:50:20.31

＞＞char* foo = "hoge";
＞＞
＞＞のようなケースではポインタ foo は文字列リテラルを指してる
＞
＞その表現が間違ってる。
＞fooは静的記憶域を指してるが正しい。

彼も文字列リテラルは静的記憶域に置かれると言ってなかったっけ
僕にはこの２つの違いが分からないや
勘違いだったらごめんなさい

2024/09/15(日) 16:04:15.59

もっと中身のある話しようぜ

2024/09/15(日) 17:53:23.56

>>68
規格に後置++演算子は実数型とポインタ型にしか使えないとあったけどそれの関係じゃないの？
規格でそう決まってるだけの話では？

2024/09/15(日) 18:13:20.02

それだな

2024/09/15(日) 21:42:32.09

ちなみに
int main(int argc, char *argv[])
と定義しても
argvは++できる

2024/09/15(日) 23:27:23.69

main の引数だけど、人によって好みがある
*argv[]だったり、 **argvだったり、
さすがにargv[][]はいないと思う

2024/09/16(月) 08:22:23.81

>>185
配列はポインタに型変換される。だから型は合うんだよ。
変更可能な左辺値でなければならないという制約に違反してる。

2024/09/16(月) 08:28:07.90

>>182-183
静的記憶域期間ってのは静的＋記憶域期間なんだよ。静的記憶域＋期間じゃないんだよ。

まあ静的記憶域期間を持つオブジェクトが配置されている場所を静的記憶域と呼んでもカジュアルな場面ではそんなに不自然ではないとは思うけど。
実装上は専用のセクションに配置するのが普通だし。

2024/09/16(月) 08:30:39.50

ここまでのまとめ

Cは生産性が低い
C使いも生産性が低い

2024/09/16(月) 10:51:57.39

ID:+a4Swf1f0 は、言語に何使おうと生産性が低そう

2024/09/16(月) 11:29:42.22

>>191,192
生産性など、君ら社畜を計る尺度に過ぎんよ。
芸術家は、時間をかけて1行の美しさを追及するものだ。

2024/09/16(月) 12:43:08.20

>>189
変更可能な左辺値に配列型は含まれないからそれとは違うん？いつポインタに型変換されてんの？

2024/09/16(月) 13:26:14.08

>>194

6.3.2.1 より
> 左辺値がsizeof演算子のオペランド，単項&演算子のオペランド，又は文字配列を初期化するのに使われる文字列リテラルである場合を除いて，
> 型“〜型の配列”をもつ式は，型“〜型へのポインタ”の式に型変換する。

式として出てくる配列は一部の例外を除けば問答無用で変換されるので ++ のオペランドに配列が出てくるときも変換後のポインタ (rvalue) に対する演算 (実際には出来ないけど) として解釈されるということでいいと思う。

2024/09/16(月) 14:56:21.22

>>195
配列オブジェクトの先頭の要素で左辺値じゃないって書いてあるな
ということは左辺値の式の中に出てくる配列は左辺値じゃなくなっちゃうということ？
なんでそんな仕様になったんだろうね

2024/09/16(月) 16:28:24.01

>>196
C には配列の要素を指すポインタとは別に配列を指すポインタというものもある。
こんなことが出来る。

int foo[10];
int (*bar)[10] = &foo;

このときの bar の型は int(*)[10] ということになるわけだが……。
型情報として長さが含まれるのはかえって邪魔だ。
大抵の配列を受け取る関数 (str系やmem系など) は配列の大きさが固定ではないから。
配列の先頭要素で配列を代表させる (それが簡単な記法にする) ほうが都合がよかったんじゃないかと思う。
配列全体をひとつの値として扱いたい場合のほうが少ないだろうという判断もそれなりに合理的じゃないかな。

いまどきの言語 (Go とか Rust とか) は範囲を表すスライスという概念を導入して解決してるけど、
C の登場時期だと 2 ワードのオブジェクトを基本型にするのってなんかヤじゃない？と思ったとしても仕方ない。

2024/09/16(月) 17:22:11.94

>>190
横からすまんが、記憶域期間って言葉も変

2024/09/16(月) 17:23:46.99

>>189
＞配列はポインタに型変換される。

それは関数呼び出しの場合だぞ

2024/09/16(月) 17:29:54.17

この糞コテは半端知識のかまちょだからNGやスルー推奨