[過去ﾛｸﾞ] C言語なら俺に聞け 163 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
99: (ﾜｯﾁｮｲ 65cd-RtM0) 2024/09/11(水)22:04 ID:+V4MmH6p0(1) AAS
>>93
別にまともでもない
配列で定義してポインタで操作できるのがCの柔軟性だから
idxにこだわると簡単な操作を複雑にしかねない
100: (ﾜｯﾁｮｲ 6663-QZ+t) 2024/09/11(水)23:11 ID:dQ20XCdF0(3/3) AAS
＞ while (*(t+i) = *s++)
これは、
＞ while (*t++ = *s++)
;これがエラーになるのは何故かと言う質問から始まったからです
t++がエラーで、t+iなら大丈夫が理解できれば解決だと思う
ポインタの理解というのは壁にはなりますが、
乗り越えれば意外と簡単です、がんばれ！
101(1): 警備員[Lv.7][新芽] (ﾜｯﾁｮｲ f931-ztXh) 2024/09/12(木)00:58 ID:QGeKjVfA0(1) AAS
>>92 ありがとうございました(sには実態がない)
gcc -S test.c
で .s を出力して眺めてみると、そのような感じになっていました
最適化と、AT&Tのオペランドが逆なのに慣れず読みにくかったですが
"hoge" は「実体」が .data に置かれ、実行時にスタックにコピーされるのかと想像してましたが、実装がどうあれ、スタッフ上に "hoge" を置くための元を実体というのは違うと思いました
実際、"hoge" は .db でアロケートされず、4字は 32ビットの数値定数とされ、スタックに即値で転記されていました(実行時に生成されていました)
# とても伝わりにくいと思いますが…
102(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 7932-IU9Y) 2024/09/12(木)08:54 ID:TbaO6N6i0(1) AAS
誰も説明してなかったことに気づいた。
E1[E2] が (*((E1)+(E2))) と等価であるというルールがある。
103(1): (ﾜｯﾁｮｲ 8a5c-8qrK) 2024/09/12(木)21:59 ID:m7IlJoP80(1) AAS
それいにしえからのバカ発見器なんだが2024年になってもまだ動いてるとはC言語おそるべし
104: 警備員[Lv.3][新芽] (ﾜｯﾁｮｲ b68a-ztXh) 2024/09/12(木)23:41 ID:+nQe2m720(1) AAS
次の方どうぞ
105: (ﾜｯﾁｮｲ a6ee-865n) 2024/09/12(木)23:43 ID:sEtsUeoh0(1) AAS
>>103
その自由度があるからC++でhtbl["key"]の様な事が出来る
Cじゃ意味ない仕様だけど、禁止する必要も無かろう
106(1): (ﾜｯﾁｮｲ 65cd-RtM0) 2024/09/13(金)08:23 ID:ykZRrldI0(1/2) AAS
>>101
"hoge"は長さちょうど32ビットだから即値でスタックに書き込むようになってるということなら
最適化によってそこまで省略されてるわけでsに実体がない件とはあまり関係ないな
最適化オフにするかもっと長い文字列で実験してみては
107: 警備員[Lv.5][新芽] (ﾜｯﾁｮｲ 1eeb-ztXh) 2024/09/13(金)09:12 ID:cjEIJ97r0(1/4) AAS
>>106
ありがとうございます
もう少し正確に書けばよかったのですが、4字と '\0' の2回に分けて転記していました
また、hogeを長くして(10字くらい？)試すと、やはり 4字ずつ整数にパックして即値で転記していました
もっと長大な文字列試せば、別にアロケートされたそれをコピーするコードが吐かれたかもしれませんが、>>92 の指摘通り、実体がなく実行時に生成されることを確認できたとして打ち切ってしまいました
108(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 65e8-hr+9) 2024/09/13(金)10:12 ID:9XTDQHQm0(1/2) AAS
C の仕様は抽象機械の動作として記述される。
抽象機械の動作をどのように実際の機械と対応させるかは自由で、見かけ上の動作が同じならどういう機械語になってもいい。
生成された機械語から言語仕様を理解しようとすべきではないよ。
低レイヤプログラミングするならどう対応付くか知る必要がある場合もあるのは否定しないけど……
109(1): (ﾌﾞｰｲﾓ MM45-bJfQ) 2024/09/13(金)10:23 ID:OBSQyTYbM(1/2) AAS
その抽象機械の定義はしょせん後付け
c言語のソースから生成されるマシン語の想像が付くようになるのはいいこと
110: (ﾜｯﾁｮｲ 6663-QZ+t) 2024/09/13(金)10:25 ID:y2ap91b60(1/3) AAS
C言語ハンドコンパイラ
111(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 65e8-hr+9) 2024/09/13(金)11:25 ID:9XTDQHQm0(2/2) AAS
>>109
機械語の想像がつくのが不要とも悪いとも言ってないよ。
そこから言語仕様を理解しようとすべきじゃないと述べてる。
できないから。
112: (ﾜｯﾁｮｲ a510-IFMZ) 2024/09/13(金)11:46 ID:HT/On1VB0(1) AAS
所詮部外者の推測。
113: (ﾜﾝﾐﾝｸﾞｸ MM7a-k+ON) 2024/09/13(金)12:46 ID:CiewPVvpM(1) AAS
今日は患者が多いですね
114: (ﾌﾞｰｲﾓ MM45-bJfQ) 2024/09/13(金)12:53 ID:OBSQyTYbM(2/2) AAS
>>111
無用な心配
Xに溢れてるクソリプと同じ
115: 警備員[Lv.1][新芽] (ﾜｯﾁｮｲ 1e86-ztXh) 2024/09/13(金)13:50 ID:cjEIJ97r0(2/4) AAS
>>108
ありがとうございます
そもそも >>88 で sの実体がないとはどういうことか、というのが疑問だったためで、言語の仕様(というか実装)がどうかには着目していませんでした
printf("%s\n", s); が .sではputs(s); に置き換えられていたり
そうだよな〜
116: 警備員[Lv.1][新芽] (ﾜｯﾁｮｲ 1e49-ztXh) 2024/09/13(金)13:59 ID:cjEIJ97r0(3/4) AAS
あー、実装には注目してるのか>自分
117: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 7932-hr+9) 2024/09/13(金)14:32 ID:7dvxgxgq0(1/3) AAS
この場合に限っては言語仕様としての理屈もあんまり違わんけどな。
ただ、正式な用語を知ってると細かいことを調べやすいみたいなのはあるので便利。
118(1): (JP 0H3e-voeu) 2024/09/13(金)16:10 ID:HymUJJD5H(1/5) AAS
gccは配列に確保した短い文字列は最適化無しでもレジスターに載せてしまってるな
ポインター文字列は最適化してもレジスターには載らない
なので配列は配列として使った方が最適化で高速化される可能性があるという事だな
119(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 7932-IU9Y) 2024/09/13(金)16:26 ID:7dvxgxgq0(2/3) AAS
ポインター文字列って変な言葉だな。
この場の造語だと思うけど
char *foo = "bar";
みたいなやつのことだよね？
文字列リテラルは静的記憶域期間 (寿命はプログラムの最初から最後まで) を持つオブジェクト。
どこかにある文字列をポインタで指しているという状況。
そのどこかにある文字は他のどこかから指し示されることもありうるので簡単には消えられない。
省1
120: (ｱｳｱｳｴｰ Sa52-t/33) 2024/09/13(金)16:36 ID:bblj+c3pa(1/2) AAS
>>93
それのどこがマトモなんだよ
>>94 の言い分の方が正しい
配列型が無いんだから
121: (ｱｳｱｳｴｰ Sa52-t/33) 2024/09/13(金)16:38 ID:bblj+c3pa(2/2) AAS
>>96
>t[100]を*(t+idx)
t[100]を100[t]
よりはマシ
>>97
だよな
122(2): (JP 0H3e-voeu) 2024/09/13(金)17:26 ID:HymUJJD5H(2/5) AAS
>>119
んなこたーない
char foo[] = "hoge";
char* bar = &foo[1]; /* 敢えてずらしてみる */
printf("bar -> %s\n", bar);
で中身は何度も参照されるぞ
gccで試してみたら敢えてずらしてポインターに代入されたとしても、レジスターに文字列を保持したままprintfに渡すというトリッキーなコードが生成されたｗ
省1
123: (JP 0H3e-voeu) 2024/09/13(金)17:45 ID:HymUJJD5H(3/5) AAS
短い配列文字列をポインターに代入したらレジスターに保持する最適化を諦めるかと思ったら、そうじゃなくて意地でもレジスターに保持したまま処理を進めるgccスゲーよｗ
clangの場合はポインターも配列も常に静的に文字列を定義したものを使ってた
124: (ﾜｯﾁｮｲ 6663-QZ+t) 2024/09/13(金)18:12 ID:y2ap91b60(2/3) AAS
最近のCPUはレジスターに文字列格納できるんだな
何バイトくらいなら入るんだろうか
125: (JP 0H3e-voeu) 2024/09/13(金)18:26 ID:HymUJJD5H(4/5) AAS
gccの場合だと64bitだと8バイトだから最大7文字かなと思ったらレジスターを複数使ってでも載せようとしてたｗ
取り敢えず50文字まで試したけど全部レジスタに載ってた
でもこの辺はレジスタの空き具合にもよるのか？詳しくは分からん
126: (ﾜｯﾁｮｲ 6663-QZ+t) 2024/09/13(金)18:41 ID:y2ap91b60(3/3) AAS
何か執念みたいなのを感じました笑
127(2): (JP 0H3e-voeu) 2024/09/13(金)18:50 ID:HymUJJD5H(5/5) AAS
スマン…間違えた…orz
正確にはアセンブリコードに書かれてると言うべきだった
movabsq $3833745473465760056, %rdx
movabsq $3978425819141910832, %rax
movq %rdx, 40(%rsp)
movabsq $3544395820347831604, %rdx
movq %rdx, 56(%rsp)
省3
128(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 7932-IU9Y) 2024/09/13(金)18:59 ID:7dvxgxgq0(3/3) AAS
>>122
その場合に参照されるのは foo であって、 "hoge" というリテラルではない。
"hoge" は foo を初期化する以外の用途に使われていない。
129: (ﾜｯﾁｮｲ 65cd-RtM0) 2024/09/13(金)20:11 ID:ykZRrldI0(2/2) AAS
>>127
データセグメントに確保するよりも
コードセグメントに書いたほうがすでにキャッシュに載ってるから高速なのかもな
130: 警備員[Lv.5][新芽] (ﾜｯﾁｮｲ 1e21-ztXh) 2024/09/13(金)20:41 ID:cjEIJ97r0(4/4) AAS
速度の最適化か、生成されるオブジェクトの小ささかのトレードオフなんだろうね
テスト用のコードは小さいから、後者は気にせずゴリゴリやってるのかな…
131: (ﾜｯﾁｮｲ fa2d-2PHd) 2024/09/13(金)23:38 ID:uRdGeQ4y0(1) AAS
世の中CやめてRustにしろだとか
OpenAIの新AIが競プロで上位1割のプログラマに匹敵とか言うじゃない
今更人間がCを続ける意義ってなんなんだろう
132(1): (ﾜｯﾁｮｲ 714e-/njq) 2024/09/14(土)00:03 ID:UIMFiyQN0(1) AAS
COBOLみたくロストテクノロジーを理解出来る貴重な人になれる
133: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 7932-hr+9) 2024/09/14(土)00:19 ID:N2YvcTj50(1/14) AAS
低レイヤに関わる資料が C を前提に書かれていたりするのは普通のことなのでたとえ C でプログラミングしなくてもある程度は身に付いてないと困ることはあるだろう。
134(2): (ﾜｯﾁｮｲ a6e1-865n) 2024/09/14(土)00:39 ID:0gsw2riP0(1/12) AAS
>>128
初期化する以外に参照されてないってのはおかしいだろ
printfで中身が表示されてんだから
ポインター変数のbar経由で中身を参照してるけど、中身は初期化で渡された文字列そのものだ
そもそもリテラルが参照されてないという言い方もおかしい
リテラルは単なる定数の簡略表記に過ぎず、ソースコード上だけの用語だ
実行時に消えてると言いたいのか？
省1
135: (ﾜｯﾁｮｲ 6663-QZ+t) 2024/09/14(土)00:51 ID:8t7wdnSS0(1/4) AAS
>>132
CobolやFortranはこれからも生き残るよ
多分
136: (ﾜｯﾁｮｲ 2a7c-9vXG) 2024/09/14(土)08:27 ID:QgTfRJpW0(1) AAS
>>134
言ってることが意味不明。
textセグメントとかbssとかdataセグメントとか知らんの？
137(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 7932-IU9Y) 2024/09/14(土)08:59 ID:N2YvcTj50(2/14) AAS
>>134
> printfで中身が表示
意味が解らん。
表示されてる中身というのは foo の中身であってリテラルじゃないだろ。
> リテラルは単なる定数の簡略表記
整数リテラルなどは右辺値だが文字列リテラルに限っては左辺値。
文字列リテラルは実行フェイズにおいてオブジェクトとしての性質を持つということ。 (抽象機械の上では。)
省1
138(2): (ﾜｯﾁｮｲ a6e1-865n) 2024/09/14(土)10:32 ID:0gsw2riP0(2/12) AAS
>>137
int i = 1;
printf("i -> %d\n", i);
この1は同じ様にリテラル表記以外に参照されてないというのか？
139: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 7932-IU9Y) 2024/09/14(土)10:49 ID:N2YvcTj50(3/14) AAS
>>138
前述の通り整数リテラルは右辺値 (rvalue)。
文字列リテラルは例外的な存在だ。
まず、 C の用語では「オブジェクト」と「値」は違う意味を持つ。
メモリ上のビットパターンがオブジェクトで、値は式の結果だ。
(規格用語では data storage だがここではあえてカジュアルな用語で言うことにする。)
そして式の結果は lvalue と rvalue に区分される。
省8
140(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 7932-IU9Y) 2024/09/14(土)12:58 ID:N2YvcTj50(4/14) AAS
>>138
このときの 1 というリテラルは (rvalue の) 1 を返す式で、その値が i にコピーされた後で寿命を終えて消滅する。
printf の引数の i で取り出される 1 は i に入っている 1 であってリテラルの 1 じゃない。
整数リテラルはあくまでも整数を返す (生成すると言ってもいいかも？) 式であって、メモリ上のどこかにあるオブジェクトというわけじゃない。
141(1): (ﾜｯﾁｮｲ a6e1-865n) 2024/09/14(土)13:32 ID:0gsw2riP0(3/12) AAS
>>140
1は破棄されて"hoge"は破棄されないんだろ？
だから参照されてんじゃん
142(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 7932-hr+9) 2024/09/14(土)13:40 ID:N2YvcTj50(5/14) AAS
>>141
>>122 の bar が参照しているのは文字列リテラルからコピーされた配列であって文字列リテラルではない。
文字列リテラルが破棄されないこととは独立した話だよ。
143(1): (ﾜｯﾁｮｲ a6e1-865n) 2024/09/14(土)13:43 ID:0gsw2riP0(4/12) AAS
>>142
barは配列のコピーじゃないだろ
ポインターなんだから
コピーしてるのはアドレス値だぞ
144: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 7932-hr+9) 2024/09/14(土)13:55 ID:N2YvcTj50(6/14) AAS
>>143
そのポインタが指しているという意味で参照してると言ってる。
なにを言いたいんだ？
論点は「配列の初期化子として現れる文字列リテラルは配列の初期化以外に使われる可能性がない」という話だろ。
145(1): (ﾜｯﾁｮｲ 6663-QZ+t) 2024/09/14(土)14:05 ID:8t7wdnSS0(2/4) AAS
＞ char foo[] = "hoge";
＞ char* bar = &foo[1]; /* 敢えてずらしてみる */
＞ bar が参照しているのは文字列リテラルからコピーされた配列であって文字列リテラルではない。
説明がよく分からないが、barは、fooではなく、どこかにコピーした別の文字列なり配列を参照していると言うことか？
146(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 7932-IU9Y) 2024/09/14(土)14:20 ID:N2YvcTj50(7/14) AAS
>>145
bar はどうでもいいよ。 それは要らん間接参照を入れて例としてよくわからんようになってるから
飛び飛びになってる私の書いてることをあらためてまとめると
・ char foo[] = "hoge"; といったような記述があれば "hoge" によって foo を初期化する。
・ このときの文字列リテラル "hoge" は foo を初期化するだけに使われて他からアクセスされる可能性がない。
・ 言語規格の建前上は文字列リテラルの寿命はプログラムの最初から最後までだが……
・ この場合は他からアクセスされる可能性がないから機械語レベルでは文字列リテラルは最適化で消えて (即値としてコードに埋め込んで) も問題にならない。
147(1): (ﾌﾞｰｲﾓ MM0a-bJfQ) 2024/09/14(土)16:37 ID:kHQOYHTcM(1) AAS
つまり
>>118 でgccが文字列を即値にする最適化の条件を推察したら
はちみつ餃子が規格の観点で説明が不適切ってぼこってるわけか？
前者の情報のほうが有益だわ
148: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 7932-hr+9) 2024/09/14(土)16:47 ID:N2YvcTj50(8/14) AAS
>>147
補足したつもりだが。
どう最適化するにしても規格に反する挙動にしてはならない (したら規格に対応しているとは名乗れない) からどうしてそれで規格に反しないのかの観点から説明した。
149(1): (ﾜｯﾁｮｲ 8af5-/VPw) 2024/09/14(土)17:01 ID:5H/bnNk90(1/4) AAS
最適化でどうなるかを考えながらC書くくらいならもうアセンブリ書いたほうが良いと思う
150: (ﾜｯﾁｮｲ a6e1-865n) 2024/09/14(土)17:07 ID:0gsw2riP0(5/12) AAS
>>146
はちみつは文字列リテラルがアセンブリソースの段階で"hoge"と書かれてなければ消えてると思ってんだなw
例え命令コードの即値で書かれていても消えてる訳じゃないからー！残念！
だから話が噛み合わなかったんだw
まぁ強いて言えば、最適化でデータの表現法方を変えても構わないって言えば良い
151(1): (ﾜｯﾁｮｲ a6e1-865n) 2024/09/14(土)17:14 ID:0gsw2riP0(6/12) AAS
x = 1; ← 最適化で消えても構わない
x = 2;
最適化で消えても構わないってこういうことを言うんだよ
char foo[] = "hoge";
"hoge"は消えて良い訳ないだろw
gccは実際、命令コードに文字列を埋め込んでスタックに生成してるが、その文字列はポインター変数を使えば参照可能だ
152: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 7932-IU9Y) 2024/09/14(土)17:26 ID:N2YvcTj50(9/14) AAS
>>149
それはそう。 原則としては言語の理屈に従っておくのが良い。
繰り返すけど、少なくとも初心者に対して低レイヤの観点で C を説明するのは筋が悪いと思う。
153(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 7932-IU9Y) 2024/09/14(土)17:33 ID:N2YvcTj50(10/14) AAS
>>151
> 参照可能だ
その時参照してるのはスタック上にある配列であって、文字列リテラルではないってのを俺は何度書けばいいんだ？
文字列リテラルは本来は「プログラムの開始から終わりまでの寿命を持つオブジェクト」としてあらねばならないのが、
実際には文字列リテラルではない形になってることを「消えてる」と表現したのは確かに微妙な表現だったかもしれないが、
有るべき場所から消えてるんだからそんくらいわかるだろ。
そもそも最初は char* foo = "hoge"; との対比で言ってたんだから。
154(3): (ﾜｯﾁｮｲ 8a56-/VPw) 2024/09/14(土)18:13 ID:5H/bnNk90(2/4) AAS
はちみつ餃子の説明はたぶん、C++ の考え方が混ざっていないか
C で配列の初期化子に文字列リテラルが書けるのはあくまで文字列リテラル限定であって、それは式として扱われるのではなく、lvalue も rvalue もクソもないということだと思うが
155(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 7932-IU9Y) 2024/09/14(土)18:35 ID:N2YvcTj50(11/14) AAS
>>154
初期化子の文法の一部であって式の規則の適用範囲外じゃないの？ってことだよね？
6.7.8 を見てこの場合でも式だと解釈してるけど、そういわれたらちょっと自信がないかも。
156: (ﾜｯﾁｮｲ a6e1-865n) 2024/09/14(土)18:53 ID:0gsw2riP0(7/12) AAS
>>153
その配列に格納されているデータが文字列リテラルから生成された文字列(の実体)だろ
厳密に言いたいなら、文字列リテラルはコンパイル時に存在さえしてれば良いものなんだよ
何しろ「リテラル」だから
それを生存期間だの実行時の実体とごっちゃにしてるから訳分かんないことになんだよ
コンパイル時にさえ存在してれば良いという事を実行時には消えてても良いとか言っちゃってんでしょ？
157: (ﾜｯﾁｮｲ a6e1-865n) 2024/09/14(土)19:03 ID:0gsw2riP0(8/12) AAS
char foo[] = { 'h', 'o', 'g', 'e', 0 };
文字列リテラルは↑のシンタックスシュガーだ
初期化子は消えても構わないのか？
初期化子が生成した文字列は参照出来ないと言うのか？
158(2): (ﾜｯﾁｮｲ 8a56-/VPw) 2024/09/14(土)19:10 ID:5H/bnNk90(3/4) AAS
>>155
外部ﾘﾝｸ:en.cppreference.com
ここ参考にしてたから文法定義の時点で式じゃないと思ってたけど、ちゃんと規格上は式としてのパースではあったね、すまない
改めて C99（でいいんだよね、6.7.8 ってことは）の draft 読んでみたけど、文字列リテラルで初期化できるのは 6.7.8.14,15 で特殊に定義された意味論であって、やっぱり式扱いじゃないんじゃないかね
159: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 7932-hr+9) 2024/09/14(土)19:58 ID:N2YvcTj50(12/14) AAS
>>154
結果的な挙動からするとどっちでも良いから書いてないだけかも。
160: (ﾜｯﾁｮｲ 6663-QZ+t) 2024/09/14(土)20:16 ID:8t7wdnSS0(3/4) AAS
皆拘らずに使っているのに言うのもあれなんだが
C言語にはC++で言う参照はありません
161: (ﾜｯﾁｮｲ a6b2-Z1Qu) 2024/09/14(土)21:01 ID:NQ2pFzob0(1) AAS
hogeは破棄されないって一人がんばってるID:0gsw2riP0を救済して差し上げたいが……自分も完全にわかってないのでできない。
162: (ﾜｯﾁｮｲ 65cd-RtM0) 2024/09/14(土)21:04 ID:tDLmxNl+0(1) AAS
実在するのはfoo[]だけで
文字列"hoge"は破壊どころか最初からあっても無くてもいいというのがここまでにわかったことだろ
163(3): (ﾜｯﾁｮｲ 7910-VVra) 2024/09/14(土)22:15 ID:zMI9sEnq0(1) AAS
配列と別に文字列もどこか別に確保しといて何の意味があるんだよ
この形で配列作る度に二倍メモリ食うことになるじゃないか
164: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 7932-IU9Y) 2024/09/14(土)22:32 ID:N2YvcTj50(13/14) AAS
>>163
せやで。 だから最適化の余地があるという話をしてる。
165: (ﾜｯﾁｮｲ 6663-QZ+t) 2024/09/14(土)22:34 ID:8t7wdnSS0(4/4) AAS
ここで最適化の話は混ぜない方が良い
166: (ﾜｯﾁｮｲ a6e1-865n) 2024/09/14(土)23:00 ID:0gsw2riP0(9/12) AAS
>>163
clangは配列でも文字列リテラルは残ってるよ
ここって想像だけで語るアホばっかだなw
リテラルはコンパイル時のみに必要
それとは別に実行時にリテラルを実体化した値が存在する
基本的にrvalueだ
でないと当然初期化が出来ない
省1
167(1): (ﾜｯﾁｮｲ a6e1-865n) 2024/09/14(土)23:04 ID:0gsw2riP0(10/12) AAS
はちみつはリテラルはコンパイル時にのみ必要な事と、実行時には必要な初期値(rvalue)を最適化で命令コードに埋め込む事を消えたと表現して、ごっちゃにしてるアホ
これが結論
168(1): (ﾜｯﾁｮｲ a6e1-865n) 2024/09/14(土)23:11 ID:0gsw2riP0(11/12) AAS
リテラルは参照されないと言ってるのがその証拠
そりゃコンパイル時にのみに必要なその場でデータ構造を表現するリテラルを、実行時に参照出来る訳ないだろw
それが出来るのはコードをデータとして表現してるLisp だけだ
C++のテンプレートでも無理
C++のconstevalなら可能になった
std::formatはそれで実装可能になった
実行時には初期化の為のrvalueが絶対に存在する
169: (ﾜｯﾁｮｲ a6e1-865n) 2024/09/14(土)23:13 ID:0gsw2riP0(12/12) AAS
constevalも文字列リテラルを参照可能なのはコンパイル時のみだった…
やっぱり真に実行時に文字列リテラルを参照可能なのはLisp だけだな
170: (ﾜｯﾁｮｲ 8a56-/VPw) 2024/09/14(土)23:40 ID:5H/bnNk90(4/4) AAS
>>1 の C17 ドラフトのリンク C++17 のやつじゃん
次スレ立てるならこれに変えといて
外部ﾘﾝｸ[pdf]:web.archive.org
171(2): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 7932-IU9Y) 2024/09/14(土)23:53 ID:N2YvcTj50(14/14) AAS
>>167
起きていることは >>127 でこれ以上なく具体的に説明されてるんだから改めて厳密に表現しないと理解できないとは思わなかったんだよ。
>>168
文字列リテラルが静的記憶域期間を持つことは 6.4.5 に書かれてる。
実行フェイズに存在するオブジェクトだよ。 (最適化を抜きにして仕様通りに解釈すれば。)
配列の初期化子として現れる文字列リテラルの扱いは微妙かもという話が >>154 >>158 の指摘だが、
記憶域期間についての記述は文脈を指定せず文字列リテラル全部を対象にした記述に見える。
172: (ﾜｯﾁｮｲ d7cd-qbvN) 2024/09/15(日)00:57 ID:/wZr5+b/0(1/2) AAS
>>163
そりゃ書き換える場合があるからでしょー
一個しかなかったら関数呼ばれるたびに初期値も書き換わってしまう
なんで悩んでるのこの人？
constつけたら一個ですむだろ多分
173(1): (ﾜｯﾁｮｲ ffe1-1pYN) 2024/09/15(日)01:17 ID:STy65/7c0(1/5) AAS
>>171
> 実行フェイズに存在するオブジェクトだよ。
存在してんじゃねーかよ！
これが最適化で消えて良いかの話だよ！
gccの場合は命令コードに埋め込んでるけど、消えてる訳じゃないし、別のポインターから参照可能だ
174(3): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ f732-vU+L) 2024/09/15(日)01:30 ID:B6k8li/O0(1/3) AAS
>>173
配列とその初期化子として現れる文字列リテラルが別の存在だってことが俺が何度も書いてることだよ。
これがそんなに何度も何度も何度も何度も書かないと理解できないようなことか？
別のポインタは配列を指せるが、その初期化子として現れる文字列リテラルを指せるわけじゃない。
char* foo = "hoge";
のようなケースではポインタ foo は文字列リテラルを指してるということと対比しての話だぞ。
175(1): (ﾜｯﾁｮｲ ffe1-1pYN) 2024/09/15(日)01:32 ID:STy65/7c0(2/5) AAS
ちなみに「文字列リテラル」が「実行時」に存在してる訳では全くない
はちみつはそこを勘違いしてる
静的記憶期間というのはスコープの事だ
まぁエクステントと言った方が正確だが
それはコンパイラーが理解できるものだが、それと「実行時」に存在する値を結びつけてはいけないし関係無い
DLLだとしたら静的記憶期間の変数も実行時には存在しない可能性もある
スレッドローカルストレージの変数もそうだな
省2
176: (ﾜｯﾁｮｲ ffe1-1pYN) 2024/09/15(日)01:38 ID:STy65/7c0(3/5) AAS
>>174
> 文字列リテラルを指せるわけじゃない。
はい、これが間違いの全て
文字列リテラルはコンパイラーだけが理解できる「構文」に過ぎない
それを実行時にさせないとはこれいかに？w
文字列リテラルは「実行時」には何て名前になってんだ？
配列でもないぞ
省2
177(1): (ﾜｯﾁｮｲ 9f56-3vlU) 2024/09/15(日)01:45 ID:hg9QOZOF0(1) AAS
>>171
なんかいろいろ書いたけど最終的には自分もそれで合っていると思う
実用上は正直どこで役に立つのかあまり思いつかないが、規格上どういう建て付けになってるのかはとりあえず理解できたかも
というか、実用上あんまり役に立つわけじゃないから今まで調べもしなかったというか
規格上は「リテラル」は存在せず integer/enumeration/floating/character は定数なんですね
それで定数は記憶域期間を持たない
文字列リテラルは静的記憶域期間を持つ
省4
178(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ f732-vU+L) 2024/09/15(日)01:46 ID:B6k8li/O0(2/3) AAS
>>175
> 静的記憶期間というのはスコープの事
ちがう。 記憶域期間はオブジェクトの寿命の区分。
6.2.4 を参照のこと。
寿命の区分が設定されている以上はオブジェクト (メモリ上のどこかにある) のこと。
> 文字列リテラルで生成されたデータは実行時には確実にアクセス可能で、消えてるなんて全くあり得ない
関数 (C のプログラムは関数の集合なので実質的にプログラムの全て) はオブジェクトではない。
省3
179: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ f732-vU+L) 2024/09/15(日)01:53 ID:B6k8li/O0(3/3) AAS
>>177
C++ の右辺値参照も左辺値参照も左辺値なんだよね。
参照を経由したら左辺値になるなら最初からそう出来ないか？ と思ったことはある。
上下前次1-新書関写板覧索設栞歴
あと 823 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.024s