C言語なら俺に聞け 163 YouTube動画>1本 ->画像>2枚

!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
http://2chb.net/r/tech/1698653580/

---

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

O2

"甲乙丙丁"[1];

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

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

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

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

>>6
> 省略できる

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

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

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

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

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

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

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

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

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

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

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

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

CGCのサイクル

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

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

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

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

#include /dev/tty

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

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

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

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

>>25
あるある過ぎる

ちち、どっかいけ

ごばくした、ごめん

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3Blue1BrownJapanのディープラーニング解説動画


現在chapter6まで和訳されてる（本家英語版は7が出た）

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

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

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

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

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

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

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

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

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

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

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

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

グワシは古語

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

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

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

#include <stdio.h>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

立て札は移動禁止です

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

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

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

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

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

int const long foo;

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

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

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

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

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

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

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

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

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

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

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

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

その程度どっちでもいい

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

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

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

これは、

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

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

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

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

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

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

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

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

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

次の方どうぞ

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

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

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

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

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

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

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

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

C言語ハンドコンパイラ

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

所詮部外者の推測。

今日は患者が多いですね

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

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

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

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

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

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

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

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

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

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

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

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

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

>>97
だよな

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

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

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

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

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

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

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

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

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

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

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

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

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

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

多分

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>151
> 参照可能だ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>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

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

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

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

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

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

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

char* foo = "hoge";

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

それだな

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

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

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

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

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

ここまでのまとめ

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

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

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

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

>>194

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

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

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

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

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

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

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

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

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

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

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

>>199
こっちは根拠になる規格の文面を提示してるんだから違うというなら違うと思う根拠を提示して。

>>188
そらargv[][]では誤りだもんな

>>187
たしかに関数の引数だと違うんだな
https://ideone.com/MR7Vqm
#include <stdio.h>

char *hoge(char fuga[10])
{
++fuga;
return fuga;
}

int main(void) {
char hage[10] = {0};
char *p = hoge(hage);
printf("%p, %p\n", hage, p);
return 0;
}

// もちろん ++hage は出来ない
https://ideone.com/xEP42d

>>197
流石に言ってる事が的外れ過ぎるのでもうちょっと勉強した方がいいと思うよ

恥ずかしながら、静的記憶域期間(で合ってるのか?)という言葉を知らなくて、ライフタイムは「静的」に含意されているのかと思ったワ…
しかし、記憶域期間って違和感あるなぁ

わけわからん
>>205は撤回します

>>203
余談だけど配列だけじゃなくて関数型も関数ポインタ型に調整されるよ。

>>201
規格に配列は常にポインタに変換されるなんて書いて無いぞ。

>>208
「常に」とは書かれていない
「ポインタに変換される」ではなく「ポインタに型変換される」

>>102がまさにそれでしょ
E1という配列が関数呼び出しでない場合においてもポインタという型に変換されているから出来ること

＞char *hoge(char fuga[10])

こう書いてあっても､関数内で10を使う訳ではない
関数内で仮に100個めの要素アクセスするロジック書いてもエラーにはならない
（実行時にはエラーになると思う、多分）

だから、
＞char *hoge(char fuga[])
添え字無しにしても良いことになる

>>210
元々ローカルでchar hage[10];と定義して10以上をアクセスしてもコンパイル時にはエラーにならないでしょ

引数に[10]と書くとしたら可読性のため(この関数では[0～9]までアクセスする可能性があると明示するため)

__FILE__ とか __LINE__ は大文字なのになんで __func__ は小文字なん？

範囲の問題じゃなくて
++hage または hage++ が出来るか出来ないかが問題なんです

一見配列を受け渡ししているように見えるけれど、
実際はポインターとして受け渡ししているってことでしょ

>>212
__func__ はマクロではないからだと思う。

#include <stdio.h>

char hage[10] = {0};

char *hoge(void)
{
// ++hage; // error '++' には左辺値が必要です。
// return hage;
　return &hage[1];
}

int main(void) {
　char *p = hoge();
　printf("%p, %p\n", hage, p);
　return 0;
}

>>214
そんなことは判ってるよ
(char hage[10]) で hage++ または ++hage 出来ちゃってる(ように観える)のが問題なんでしょ
関数の引数は (char hage[]) または (char *hage) のみにすれば良かった
(char hage[10]) はどうみても蛇足(結局境界テストされてないし)

問題だと思う人は、使わないようにしましょう
開発サイトでそういうルールを用意するのも手です

>>215
納得しました。

>>197
そもそもstr系mem系はアドレスを受け取るんであって配列を受け取る関数ではないっていう勘違いがあるんだけど
それはともかく大きさがどうのとかなんちゃらが都合がいいとか、本当にC言語でなんかプログラムを書いた事あるの?

俺は尻より胸派なんだよね。

>>217
この場合に限らずｃでは範囲チェックなどされないでしょ
必要なら自分でチェックするのが原則

void aaa(char hage[10],int idx)
{
if((UINT)idx < sizeof(hage)/sizeof(hage[0]))
printf("%d=%d¥n",idx,hage[idx]);
else
printf("%dは範囲外だhage¥n",idx);
}

これなら[10]に意味が出る

ド素人w

>>222

c faq 6.21 (英文が詳しい)
https://c-faq.com/aryptr/aryparmsize.html
>>207 の'調整'は'adjust'だろう
N1256を'adjust'で検索するのじゃ
Look, a new day has begun.

8/16bit時代の1バイトでも、1ステップでも減らせってのを経験した人と
最近の可読性、移植性、安全性優先設計が当たり前世代とのギャップ。

ギャップの問題じゃねーから
文脈すら理解できないじじいはすっこんでろ

専門板によくいるアスペだな

225 は釣りでしょう

>>222
sizeof(hage) で配列のサイズが求まるの?
と思ったら、「char * (ポインタ)の大きさを返すよ」みたいな警告が @gcc

釣りだか天然だか、分からなくなってきた 笑

今どきの統合開発環境を使ってるなら変数の型くらい見れると思うけれど
古典的な手法としてあえてエラーにしてメッセージを読むという型の確認方法がある。

void foo(char bar[10]) {}
int main(void) { int baz = foo; }

こんなコードをたとえば gcc でコンパイルを試みると

error: initialization of 'int' from 'void (*)(char *)' makes integer from pointer without a cast

というエラーになる。
foo の型が void (*)(char *) であることがわかる。
foo は関数型の式 (関数指示子) なので暗黙に関数ポインタに型変換されているのと
bar に相当する箇所の型が char* になってるのがわかる。

なるほど
勉強になります

>>222
＞この場合に限らずｃでは範囲チェックなどされないでしょ
＞必要なら自分でチェックするのが原則
＞
＞void aaa(char hage[10],int idx)
＞{
＞ if((UINT)idx < sizeof(hage)/sizeof(hage[0]))
＞ printf("%d=%d¥n",idx,hage[idx]);
＞ else
＞ printf("%dは範囲外だhage¥n",idx);
＞}
＞
＞これなら[10]に意味が出る

printf("%uz\n", sizeof(hage)/sizeof(hage[0]));
の結果ってどんな値表示されるの？

書式のとのuzじゃなくてzuだっけ？zだけでよかったっけ？
ま、主旨はそこじゃないからいっか。

>>233
sizeof(char*)/sizeof(char) ということになる。
sizeof(char) は確実に 1 だから結果としては単に char* のバイト数ってことだね。

この場合は「『もし 10 に意味があるとしても』境界チェックはされないことに変わりないのでなんの役にも立ってない。 役に立てるとしたらここまで書かなきゃならない」というのが主旨なのであくまでもしもの話。
実際の値はどうでもよい文脈だと思う。

>>224
ああそうなの
昔のことだから記憶違いをしてたようだ

>>235
>>222 の「これなら[10]に意味が出る」ってのは間違いってことね。

'ここの10は意味ありませんよ'
って警告を出してもいいじゃんってことでしょ
それなら例えば

typedef char HAGE_TBL[10];
void foo(HAGE_TBL hage) {}
(毎回10とか書くのは危険なのでこういう使い方が多いと思う)

などとした場合に毎回警告が出てうざいことになるんじゃないか

警告ならまだ笑っていられるが、
明らかに書いた奴の意図とは違って誤動作してるだろ

>>222 のバグを晒すスレはここですか？

C言語は難しいな

void aaa()の中で、
引数で渡された値が何かを確かめて見ると良い
それと、 sizeof(hage)やsizeof(hage[0])の値も

プログラム書いた人の意図としては、
sizeof(hage)/sizeof(hage[0])が10になるはずなんだが
さてさていくつだろうか？

もうやめて！>>222 のライフはゼロよ！

本人が新たなネタを出してくるんだもん。
>>238 でもわざわざ
typedef char HAGE_TBL[10];
ってやっておきながら、なんで
void foo(HAGE_TBL hage)
なの? 構造体と同じように
void foo(HAGE_TBL *hage)
ってしてみたら新たな何かが見えてこないかい?

cは洗練された型システム持ってないんだからそんなところ頑張っても無駄なんだよ
この悟りに至って始めて脱初級
原則語るならそれからにしてくれ

Cは一部の洗練された型システム持つ言語よりも遙かに自由度が高い
そこが分かってようやく中級レベル
あとは本人の努力次第で空も飛べるし海も潜れる

おいおい
そのぶん危険なんだから持ち上げる部分でもないだろ
お前も初級

ナイフは危険だが有用
不器用者は使わない方が良い

>>244
typedefは新たな型を作るわけじゃない別名を定義するだけから

void foo(char hage[10])
と
void foo(HAGE_TBL hage)
は同じことだよ

>>248
c言語ってとっくの昔から自由にキャストしまくれる言語じゃないの知ってるか？
さぁお前はなんと答える？

そんなに怖がるなよ
食われるわけじゃないんだから

>>245
悟った人は全部void*

文字も数字も全部intでいいやん

getch() は int

>>249
それが不満なようだから「HAGE_TBL * にしたら何ができるか考えてみては?」ということでは?

昔のコンピュータはメモリー少ないから、intで文字持つなんて贅沢だったんだよ

次のジジイの的外れな言いたいだけコメントを先取り
intは16bit以上だぞ

違うよ、intは処理系依存だから8ビットの場合もある

規格書読め

次のジジイ
getcharがなぜintを返すか

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

（単に端折っただけかもしれないけれど、）文字列リテラルに関してCには非常に込み入った事情(Rationale Rev. 5.10 6.4.5 冒頭-l.26, N1256 Annex J.5.5)があり、厳密に言えば foo は "hoge" によって初期化された無名の配列を指している(N1256 6.7.8-32)。

C99RationaleV5.10
https://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf
テンプレ入りキボンヌ

>>皆の衆
ともあれ、込み入った事情に該当しなければ
const char afoo[] = "hoge";
あるいは
const char * const ccfoo = "hoge";
場合によって
const char *cfoo = "hoge";
と書いて、うっかり書き換え防止に勇往邁進するのじゃ。

>>158
件の意味論は 6.7.8-32 を介して 6.7.8-14,15 に帰結するように思われる一方で、文字列リテラルが 6.4.5-5 で自ら初期化した（やはり）無名の配列の代名詞だとすると 6.7.8-11 が適用されるという解釈も成り立ちそう。

char *gfoo1 = "hoge"; // (1)
char *gfoo2 = "hoge"; // (2)

void f() {
char *foo1 = "hoge"; // (3)
char *foo2 = "hoge"; // (4)
}

>>261 で触れた文字列リテラル書き換え派の場合、(1)～(4)は別物なので、各々初期化しなければならないため前者の解釈。この時、(3), (4)が automatic storage duration でも良いように 6.7.8-32 では storage duration を定めていないのだと思う。
他方、文字列リテラル不変派の場合、(1)～(4)は同一で良いので、初期化を一回で済ませて後者の解釈。
結局、前後者両方の解釈が出来るようになっているように見える。

まだやってるキモ…
いくら話題無いからってこれは誰も幸せにならない

ええんちゃう別に
どうせ5chに答えを求めてやって来る人なんてもうおらんのやし

青い鳥を探してます
ここに来れば教えてくれると聞いて来ました

PythonとかC++のスレで規格持ち出して言い合いしてるのを見たことないが
何故かここではよく起こるな

Cなんてのは対象CPUの違いとかでも標準とかけ離れた実装して来るのにね

>>264
これ++

>>266
じゃあ何を根拠にしてるの？
妄想？

perlあたりで頼む

>>269
君の問題点は規格読んでるの間違えてるとこだよ

>>271
規格を根拠にしてたら間違えてる箇所は間違えていると反論できるだろ。
根拠がないよりは良い。

ところでどこに間違いがあった？

>>235
これの1行目は文字列長によらず固定値にならない？
char* と char[] を区別できてないように思う

// これは (ヌル文字を含む) 4バイトのデータがスタック上に作られる
// sizeof(a1) の結果は文字列数により変わる
char a1[] = "abc";

// こう書いた場合、文字列の実体は静的な領域 (テキスト領域) に確保され、
// a2にはそのアドレスが渡される。
// sizeof(a2) はポインタのサイズであり、値は文字列長によらず固定
char* a2 = "abc";

char* でも char[] でも、a[n] と書けばn文字目を参照するのは変わらない
これはポインタの [] 演算子は「ポインタをn個進めた位置の要素を参照する」ため、結果的には配列と変わらないから
だけど前述の a1 と a2 は違う型なので、そこは注意が必要

たぶん VS Code でC言語の拡張を入れてれば、上記のように書いた変数のところにカーソルを当たるとヒントが出るので、それで確認できると思う
それか実際に動かして sizeof の結果を見るか

>>273
> これの1行目は文字列長によらず固定値にならない？

その通りだよ。 固定値になってたぶん意図通りではない。
その話は >>222 がボコボコに言われてもう終わったよ。

もう >>222 を晒すのはやめてあげて......

222は釣りでしょう

あ、ひょっとすると >>273 は話題を誤解してるのか。
「仮引数が配列形式だった場合にポインタに調整されるルール」が話題の中心。
仮引数として現れないと意味ない。

>>278
すまん自分が直近のレスだけ見て話題を早とちりしてた
だいたい流れは分かった

初歩的な質問で申し訳ないんだけど
プログラムをユーザーの入力によって一時停止させるのってどうしたら良い？
pauseで入力待ちにするとかフラグを間に挿入するとかではなくユーザーからの入力があった場合のみ一時停止したい

まずメインの処理を一時停止可能な作りに変える

>>280
ソースコードの中にファイル名がpauseのファイルが存在するかを判断するロジックを追加
もし存在するならループに入りそれが消えるまで待てばいい

あとコンソールプログラムなのか？
環境を正確に書きな

>>280
C は言語として規定している範囲はかなり狭くて、細々とした制御には環境依存の方法が必要になることが多い。
ホスト環境によって作法が違う。

>>281
根本からなのね
>>282
初心者なもんで、一つのファイル内で完結したら嬉しいなーなんて
>>283
とりあえずコンソールで作ってる
環境はVS2022だけでおｋ？
>>284
ちょっと前古いサイト参照してたら環境違いすぎて苦労したし古い言語の宿命なんすかね

環境依存でデバイス依存だからなぁ

やりたいことがnon blockingでgetcharしたいってことだとするとwindowsだconsole apiを使う
例えばwindowsのreadline互換実装であるwineditlineを見るといい

ただめんどうなので今回のように止めたいだけならこういう簡易的なやりかたがある
https://stackoverflow.com/questions/21294713/non-blocking-i-o-in-c-windows

>>287
一行目の通りで合ってると思う
念の為やりたいことを挙げておくと、メディア再生中の一時停止とかゲーム中のポーズ画面みたいなものだと思ってもらえれば良い
ただ、2行目のreadlineは日本語でググったりヘルプで検索かけたけどよくわからん
>>288
すごい簡単だね、これなら作れるかもしれない
入門書に記載がないのが唯一の不満だよ

>>285
言語の古さというより用途だろう。
低レイヤ部分を実装する用途に使う言語だから重厚なランタイムサポートを必要とする機能は入れられない。

いにしえの議論掘り返してすまんが、>>182の例示による説明が最も本質を突いてるように思う、感謝のレス

文字列リテラルは配列初期化子の構文糖でありながら、また文字列をも表すという二義性を持つ、という云うのはあくまで言語設計の為の汚いハックでしかなかろ？

Cの変数の型指定なんて気休めだからなぁ

気休めじゃなくて気疲れの間違いだろ
長さやsignednessでわけわからん変換しやがるバグの根源と言ってもいい

訳が理解できるようになるまで､お前は使用禁止

https://togetter.com/li/1471386
こんな事本当にあるのか？

もともとバグってたのを対処療法で回避しただけじゃねーの？
そんな驚愕するほどのこととは思わんな
スペースは文字列に加えるってことだろ

ちゃんとソースを公開すればみんなで治してくれるよ

バイバイおさるさん

char []s = "うんこ"
s[20] = 0; // どっか判り難いとこにこんなのが紛れてる
回答「(sに)もっとスペースを追加して！」

どこか知らない国で "うんこ" が40バイトくらいある所があったりして

業務だとヨソの担当のモジュールに口出しするのがめんどいから対処療法で握りつぶすみたいなことはあるのかもしれん。

s("※んこ"の値)は読み取り専用になるんじゃないかな
処理系によるかもしれないけど

>「ここにスペースを入れてみて」「もっと沢山、もっともっと」
この辺りコピペ怪文書にしか思えないんだが
境界チェックしない言語ならありふれたバグだし、元文書はちんぽとかだったんじゃないだろうか

どうせメモリーリークだろうな
データ位置を変えると現象が変わるなんて典型的だろ

>>302
誤りでした

パンパース当てるのが正しい

おむつってあんま進化してないよな
吸収率だとか漏れだとかそんなのは上がってるだろうが、基本的な機能は変わらない
介護業界でも排泄介助っていう高齢者の汚物処理って割と大変な部類だと思うんだが
そろそろおもつ革命を起こさないと業界崩壊するんじゃないの
プログラミングでなんとかできませんかね

高齢者に限らず若い子でもうんこ漏らす時は漏らすし、そういう緊急時にも安心できるぐらいのものがそろそろ欲しいな
紙ベースで吸収率だとかで脳が退化してるおむつメーカーではおむつ革命はとても期待できないだろう

介護対象に飲ませるうんこがあまり臭くなくなる薬みたいな技術は進化してるぞ

薬で臭くなくしたうんこだからといって介護対象に飲ませるのはどうかと思うぞ。

>>310
完全に臭くなくなる訳ではないのでおｋ

ニホンゴ　ムズカシイネ

逆に考えるんだ。うんこはどうしても出てしまう。だったらそれはそのままにしておけ。
介護する側がそれを気にせず処理出来るのであれば問題は消滅する。だから介護者が
それを気にならなくなるような精神に効く薬を作れば良いんだ。

>>295って実行時エラーの話なのかコンパイル時エラーの話なのかもわからなくない？

NASAはネットなんてなかった1970年代にボイジャー1号打ち上げて
240億km離れててもプログラムを送受信してるのに俺らときたら

どうみても脳筋エラー

脳筋がCを使いません

240億kmの伝書鳩

1970年代にもテレビやラヂオはあったわけでね…

1960年代はラジオ少年が秋葉原詣でしてたな

質問失礼

LPTSTR lptStr = TEXT("テスト");
って書くとE0144とC2044ってエラーを吐くんだがプロパティの文字セットって項目を設定なしにすると正常に処理されるのはどういう理屈なの？
const wchar_t[]からLPTSTRに変換できませんってメッセージ出るし型が違うのかなと思うが
だとしたら何故文字設定いじれば解消するのかもよくわからない

LPCTSTR ではダメですか?
当てずっぽうですが

>>323
そういうことじゃないのか、ごめんなさい

>>322
設定変えても依然エラーだが
VS Community 2022

>>324
気持ちだけで十分よ

>>325
2022だと設定項目見つからなかったから2012でやった、そしたら上記の結果になるんすよねえ

最近のVSはCの当たり前な構文が通用しないから困るよな

>>328
Visual Studio側の問題なのこれ？

>>327
2022で設定変えたって書いただろ
あほなのか

LPTSTR lptStr = L"テスト";

あと
#define UNICODE
#define _UNICODE
だったかな

それでもだめなら
文字コードが違うんじゃないですかね

>>330
どストレートな罵倒は久しぶりに聞いたよ
高校上がってからは聞かなくなったけどね

>>331
ありがとう、だけどダメそうだ
文字コード関連のエラーなんだろうけどどうしたものか

char と wchar_t の不整合じゃなくて const の有無の問題じゃないの？

C++ で文字列リテラルまわりの扱いで仕様変更があったからそれに関係してるのかも？
C++ での文字列リテラルの型は const char[] (ワイド文字リテラルの場合は const wchar_t[]) だが、文字列リテラルから直接変換する場合に限り char* (ワイド文字リテラルの場合は wchar_t*) に暗黙に変換して構わないというルールが C++03 まではあって、このルールは C++11 で削除されたという経緯がある。
つまり C++11 以降は文字列リテラルから暗黙には const を剥がすことが出来ない。 (キャストを書けば出来るけど。)

C では文字列リテラルの型は元から char[] で、 const が付いてない。
だから const まわりの制限とは関係ないんだが、これは C の仕様のほうがおかしいし、 C++ と同様の判定をしたほうが理に適っているとマイクロソフトが考えることはあるかもしれない。

E0144 エンティティの初期化
型”cont wchar_t *"の値を使用して"wchar_t *"のエンティティを初期化することはできません

C2044は関係無い

>>336
なるほどね、LPTSTRがchar*だから代入できないって話になるのか
それがわかったらエラー文にかいてあることが理解出来るね

昔の仕様だとconst charに見えて実際は違かったってこと？
それなら今回のコードもエラー吐かないし悩まなくてよかったのに

>>337
関係ないの？LPSTRに代入できませんって言ってるように見えるけど

signedとunsignedでも怒り狂うからなぁw
いいんだよ、こっちは中身しってんだから余計なエラー吐くなよ

>>338
> 昔の仕様だとconst charに見えて実際は違かったってこと？

C の規格としては本来的に文字列リテラルの型には const は付かない。
これは今も昔も同じ。 変更はない。

なので何かが変わったとしたらマイクロソフトの独自仕様。
私はそのへんに詳しいわけじゃないけど C++ の規格改定に引きずられた可能性は想像できるなぁというぼんやりした予想なので経緯はわからぬ。

でもまあ結果的に const の問題ってのは妥当なみたいだね。

LPTSTR lptStr = (LPTSTR)TEXT("テスト"); で警告出たりするのかな？
糞面倒だけどキャストで通るならそれ以上の対応不用

VS使ってるからたぶんCじゃなくてC++
こういうボンクラの自覚ないボンクラは相手しても疲れるだけ

>>341
理解した
constは付かないはずなのにリテラルにVisual Studioが勝手に付いてることにしてくるってことね
わざわざありがとうスッキリしたよ

>>342
いけた
たしかに面倒だけど仕方ないね

>>343
そんなこと言いながら何回もレスくれるなんて

>>315
どっちもいける

実行時エラー
https://wandbox.org/permlink/r9w30EwoyKVxIguC
> Segmentation fault

コンパイル時エラー
https://wandbox.org/permlink/yPJz2UPs8xHYPLAr
> prog.c: In function 'main':
> prog.c:8:17: error: '%d' directive writing 11 bytes into a region of size 1 [-Werror=format-overflow=]
> 8 | sprintf(s, "%d", INT_MIN);
> | ^~
> prog.c:8:5: note: 'sprintf' output 12 bytes into a destination of size 1
> 8 | sprintf(s, "%d", INT_MIN);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors

左辺をLPCTSTRにすれば良くない？
リテラルの文字列を可変にすること自体が本来は不要だし、右辺を可変にキャストするよりは左辺を不変として (LPCTSTRとして) 受け取れば良いと思う

>>344
オンラインコンパイラで VS17.10 を確かめてみたが文字列リテラルには const は付かないぞ。
お前が間違って C++ を使ってるという >>343 の意見に一票。

>>322
・Microsoft Visual Studio Community 2022 (64 ビット) を使用し「C++コンソールアプリ」で新規プロジェクト作成
・ソリューションエクスプローラーでソースファイルにあるファイル名を*.cppから*.cへ変更
・ファイル名を変更したファイルに下記をコピペ
#include <windows.h>

int main(void)
{
LPTSTR lptStr = TEXT("テスト");
}
・ビルド(B)→ソリューションのビルド(R) でフツーにビルド通ったわ。

つまりスレタイ嫁ということか

>>343 は速攻ぶったたいてるが、学生か初学者はこういう経験しとくもんだ
Cは汗に似て泥臭いんだよ

俺もあとで追試しよっと テキトーでやってて知識整理できてないわ

>>322
コンパイラオプションを見れば明らかになるじゃろう。

EchoAPIがVS Codeのワークフローにピッタリで、APIテストの能力がグッとアップしったって聞いて

まるちんこしね

Q.
doubleをprintfで表示するには%lfでいいの？

A.
double 型を printf で表示する場合、%lf ではなく %f を使用するのが一般的です。

理由:
printf の可変長引数において、float 型は double 型に自動的に昇格されます。
そのため、%f は double 型の値も受け取ることができます。

%lf は scanf で double 型の値を読み込む際に使用されますが、
printf では %f と同じ意味として扱われます (C99規格以降)。

これが同じ値書いてくれないのは普通だったんだっけ．

#include <stdio.h>

int main() {
int s=31;
unsigned long i = 1 << 31;
unsigned long j = 1 << 31;
unsigned long k;

while(i) {
k = 1 << s;
printf("%lu,%lu,%lu¥n",i,j,k);
i = (unsigned)i>>1;
j >>= 1;
s--;
}

return 0;
}

手元にあるGCCとMS-C(32bit)は
同じ値が出てました

質問失礼します
ダイアログボックスについて学習しようとしているのですが、サンプルのリソースをコピペしたところ、ダイアログボックスのIDが認識されなく手詰まりになってしまっています。
どなたかご助力ください。

TEST DIALOG (座標を書くと書き込みできない)
C2059
C2061

以上のソースでエラーを吐いてしまいます。リソースをベタ打ちで記述する参考サイトが少ないので判断がつきません。

記述に文法上の誤りがあるって事です。
コピペで失敗しているのか、
元々のサンプルに誤りがあるかは
これだけでは分かりません
文法の基本から学び直して
自分で見つけるしかないかもしれません

>> 358
試していただきありがとうございます．
FreeBSD clang version 18.1.6 (https://github.com/llvm/llvm-project.git llvmorg-18.1.6-0-g1118c2e05e67)
Target: x86_64-unknown-freebsd14.1
と，gccは共に jの値がおかしいのです．
試しに，
unsigned long j = 1 << 31;
を
unsigned int j = 1 << 31;
にすると同じ値になる．

これはコンパイラのBUGかなぁ．

よく分からないけど
unsigned long i = 1 << 31;
unsigned long j = 1 << 31;
を
unsigned long i = 1L << 31;
unsigned long j = 1L << 31;
とするとうまくいく？　clang

どちらでも同じ結果になりそうだけど
見当違いだったらごめんなさい

gcc -S
でアセンブラ出してみてみたけど、
いや、アセンブラよくわからないんだけど、
修正前の iと jは初期化時にいずれも符号拡張されて大きな値になっていて
その後なぜか iの方は下32ビットで、jの方は64ビットで計算されているようで、正しいのはむしろ jのように見えたがごめんなさい
本当にアセンブラ分からないので多分間違ってます…

gcc, clang
sizeof(int) == 32
sizeof(unsigned long) == 64
での出力

18446744071562067968,18446744071562067968,18446744071562067968
1073741824,9223372035781033984,1073741824
536870912,4611686017890516992,536870912

省略

8,68719476728,8
4,34359738364,4
2,17179869182,2
1,8589934591,1

これはこれで正しいと思うが

あ、iは unsigned (int)でキャストしてるのか

わかりやすく，intのものとcastかけたのにしてみました．
これだとやはり，pの値だけ変でした．

元々は，binaryで数を8bit 16bit 32bitで表示する関数が，8,16が普通で32だけ変なので気がついたのでした．なんでintだと符合拡張されなくてlongだとされるかが謎．

#include <stdio.h>

int main() {
int s=31;
unsigned long i = 1 << 31;
unsigned int j = 1 << 31;
unsigned long p = 1 << 31;
unsigned long k;

while(i) {
k = 1 << s;
printf("%lu,%u,%lu,%lu¥n",i,j,k,p);
i = (unsigned)i>>1;
j >>= 1;
p >>= 1;
s--;
}

return 0;
}

unsigned long p = 1 << 31;
を
unsigned long p = 1L << 31;
にしたら同じ値になりました．

ううむ，なぜ
unsigned int j = 1 << 31;
だとうまくいって，longだと1Lにしないとうまくいかんのだ．

右辺が 1<<31だと
左辺が intだと0x80000000がそのまま、
longだと 0xffffffff80000000に拡張されて転記されるからでは

unsigned long i = (unsigned long) 1 << 31;
とすれば iは 0x80000000になるかと

1lとするのと同じだけど

>>367
言語仕様的に解釈すると……

シフト演算子の結果の型は左オペランドを整数拡張した後の型と同じになる。
整数リテラルは int の範囲で表せる限り int なので 1 は int 。
int は整数拡張の必要がないので 1<<31 の結果の型も int 。

そして結果の型が signed かつ結果の値が結果の型で表現可能な範囲にないときの動作は未定義なので
2147483648 が int (おそらく質問者の環境では 32 ビット) の最大値である 2147483647 を越えていて未定義の挙動となる。

不定とか処理系定義ではなく未定義と明記されてる。
つまり言語仕様上は何が起きても良いということ。

6.3.1.3のこれじゃないの
Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or
subtracting one more than the maximum value that can be represented in the new type
until the value is in the range of the new type.

6.3.1.3

符号付き整数型及び符号無し整数型 整数型の値を̲Bool型以外の他の整数型に変換する場合，

その値が新しい型で表現可能なとき，値は変化しない。

新しい型で表現できない場合，新しい型が符号無し整数型であれば，新しい型で表現しうる最大の数に

1加えた数を加えること又は減じることを，新しい型の範囲に入るまで繰り返すことによって得られる値

に変換する(49)。

なるほど，1がintで<<31すると負の最大値となって，unsignedとして表せないからか．

皆様，ありがとうございました．

>>372-373
いいえ。
シフト演算の段階で既に未定義を踏んでいるので型変換は関係ないです。
6.5.7 をご覧ください。

科学 ＋ ンニュース 5ch

保守派もリベラル派も「自分の政治的信念に合致したニュース」を信じやすいという研究結果 [すらいむ★]
http://2chb.net/r/scienceplus/1732447647

コメントも含めて読むと
陰謀論が収まら無い理由が判明する

なるほど、32bitのみでやるときも1u<<31にしないといけないのか

なぜ浮動小数型をシフトしようとした？

>> 374 なるほど，そっちで既に未定義だったか．

6.5.7
ビット単位のシフト演算子
構文規則
シフト式：
加減式
シフト式 << 加減式
シフト式 >> 加減式
制約 各オペランドは，整数型をもたなければならない。
意味規則 整数拡張を各オペランドに適用する。結果の型は，左オペランドを拡張した後の型とする。右オペランドの値が負であるか，又は拡張した左オペランドの幅以上の場合，その動作は，未定義とする。
E1<<E2の結果は，E1をE2ビット分左にシフトした値とする。空いたビットには0を詰める。E1が符号無し整数型をもつ場合，結果の値は，E1×2E2の，結果の型で表現可能な最大値より1大きい値を法と
する剰余とする。E1が符号付き整数型と非負の値をもち，E1×2E2が結果の型で表現可能である場合，それが結果の値となる。それ以外の場合，その動作は未定義とする。

E1>>E2の結果は，E1をE2ビット分右にシフトした値とする。E1が符号無し整数型をもつ場合，又はE1が符号付き整数型と非負の値をもつ場合，結果の値は，E1/2E2の商の整数部分とする。E1が符号付き整数型と負の値をもつ場合，結果の値は処理系定義とする。

VS CodeでEchoAPIを使うと、ツールを切り替えずにAPIテストをシームレスに管理できるようになったよ！

以下のサンプルプログラムが理解できず困っています。
該当プログラムは、コマンドラインから読み込んだBMPの色データを矩形として並べていくというものの一部を抜粋しています。

以下のfor文は
カラーテーブルの数を取得する→
ブラシを設定する→
先頭の構造体メンバからiCount先の構造体メンバを指定→
iCountにインクリメント

という流れだと考えられると思うのですが、１に対し1カラービット分左シフトとなっている部分がどういったロジックによって数の取得が実現されているのかわかりません。
質問は2点あり、どのようにしてテーブル数を取得しているのか、コードの理解は正しいのかについてお答えしていただければと思います。


サンプルコード

#include <windows.h>

BITMAPFILEHEADER bmpFileHeader;
BITMAPCOREHEADER bmpCoreHeader;
RGBTRIPLE *prtColor;

for ( ; iCount < (1 << bmpCoreHeader.bcBitCount) ; iCount++) {
SelectObject(hdc , CreateSolidBrush(
RGB( (prtColor + iCount)->rgbtRed ,
(prtColor + iCount)->rgbtGreen ,
(prtColor + iCount)->rgbtBlue
))

bcBitCountはピクセルあたりビット数で1,4,8,24だそう
nビットで表せる値は2^n通りで、これは左シフト1<<nで計算できる

# 質問されていない部分だけど…
iCountと比較する値はループ内で変動しないよね？
だったら毎回計算せずにループ前で計算して別変数に記憶しておくほうがよくないかい？

今時のコンパイラは十分賢いので気にすることない

ユーザーの犯したバグも直してくれるとありがたいなあ

シフトでも掛算でもどっちでもいいけど
質問者のように読んで悩むのは問題
コメント書いておけ

ループ内毎回計算か最適化でループ外に出したかは
コンパイル後の逆アセンブルとかで確認するの？
だったら間違いないようにループ外に出す方が良い癖にもなると思うのだが

380の知能では最適化したつもりが新たなバグを埋め込む事になるかもしれん
自身の身の丈に合ったコードにしとけ
未来の自分が賢くなってる事を信じて

#include <windows.h>

BITMAPFILEHEADER bmpFileHeader;
BITMAPCOREHEADER bmpCoreHeader;
RGBTRIPLE *prtColor;
↑
この間に何も描かれてないのは投稿者が勝手に削除したの？元から無いの？
↓
for ( ; iCount < (1 << bmpCoreHeader.bcBitCount) ; iCount++) {
SelectObject(hdc , CreateSolidBrush(
RGB( (prtColor + iCount)->rgbtRed ,
(prtColor + iCount)->rgbtGreen ,
(prtColor + iCount)->rgbtBlue
))

なんでこんなに読めないのか理由がわかった
変数名や字下げや「,」前のブランクなど
論理そのもの以前にコーディングの美しさが全然無い

この掲示板書き込むと、スペースやタブは消されちゃうんだよな。
だから綺麗に整形した状態でソース載せたいなら、
全角スペース使うしかない。
あるいはソース公開出来るサイトにアップロードして、
そのリンクを張るなりする。
そういうサイトは、>>1 に書いてある。

美しさとか言い出したら自転車置き場の議論なるからやめとけ

http://2chb.net/r/tech/1402617355/

色々試し書きしたいなら、テストスレがあるから、そこでやって

python自体のスタイルPEP8に加えてCについてのPEP7も整備されているのに
https://peps.python.org/pep-0007/
あえてそれに背くコーディングをする理由が見つからない
GNUのへんてこコーディングも規約文章は整備されている

他人のふんどしででかい顔のpythonは存在自体がきしょくってぇ
そんなもん使ってる奴の押し付けに従う気にはとてもなれないって感じぃ

自分の使ってるテキストエディタにコピペして整形を実行したら一瞬でどうとでもなるんだからどうでもいいだろ。

func(a , b , c );
func(a, b, c);
上から下への変換はインデントとは異なりやっかい

>>395
どんな古臭いフォーマッタを使ってるんだ？

>>381
シフト演算を行った場合、10進数の1に対して乗算を行うわけではなく、2進数に対して行うという認識で良いでしょうか？
すなわち、この場合を10進数で表すと、1ではなくて2に対して、1,4,8,24、のいずれかを冪乗し、何通りの色の組み合わせがあるのかを確かめることができるというわけですね。

>>382
コピペしただけなのでとりあえず理解をと思い書き込みました。自身で書くときはそうしたほうがわかりやすいかもしれませんね。

>>385
少し別添えで記述されてはいたのですが、それだけでは理解に至らなく書き込みした次第です。


>>386
そうなんです、私も身の丈に合うコードにしたいのは山々なのです。
ところで、初級者向けのGUI作成の手引書を教えていだだけませんか？もちろん、ここ5年以内の環境で

>>387
勝手ながら削除しています。素人考えなのは承知です。
仕事柄、利権や法にはうるさくあらねばなりませんので、リスク回避です。

Cは知っといた方がいいけど
GUIをやりたいならこのスレに居るのは時間の無駄なんだが
そのBITMAPなんちゃらも以下の環境では気にしなくていい

GUI開発おすすめ言語
iOS macOSアプリ Swift、Objective-C
Androidアプリ Kotlin、Java
Webアプリ Kotlin、Java
Windows C#
なおWeb系はHTML/CSS、JavaScript/TypeScriptは必須と思って頂きたい

Windowsの内部構造を知るのは時間の無駄なのか

BITMAPなんちゃらに詳しくなった所でWindowsの内部構造を知ったことにはならないんだがぁ？
現行Windows11の内部構造なんてきしょすぎてそもそも知りたくもないわ

そういう人はソフト開発に向いてないよ

bmpCoreHeader.bcBitCount の範囲チェックが必要そう
uint64_t max;
max = 1 << 64; // max == 0x8000000000000000 で意味がありそう
max = 1 << 65; // これ64bit整数の範囲超えているよね、プロセッサ依存の値になる予感

64bitシフトでも溢れた
これ難しいね
uint64_t seed, max
seed = 1;
max = seed << 63; // 0x80000000 で期待どおり
max = 1ull << 63; // 0x80000000 これも期待どおり
max = 1 << 63; // 即値1のレジスタ範囲が足りない？
max = 1 << 63; // 即値1だと32bitなのか

カラーパレットを使うのは1,4,8って決まってるんだが

トリプルポインタが理解不能です。

1, 4, 8以外のエラー処理が無ければ手抜きプログラムだよ

これが俗に言う無能な働き者かぁ…

粘着キショい

>>407
理解してる俺でもデバッグん時に面倒だから使わない

理解するな、感じるんだ！

スマホ世代もCってるなんて頼もしい限りだな

なんだその数字w

>>413
なんていうアプリで書いてるんだろ？

>>415
アマゾンにあった
「 モバイル C { C/C++ コンパイラ }　」だって
￥1,546
/dp/B00MFXHPBW

無料版もあるみたいだ。違いは分からなかった。

/dp/B01CEZQGX8

なんかEchoAPI、さまざまなAPIシナリオをモックするのに役立って、フロントエンドの作業を独立して行えるようになるよ

前はAIDEってのもあったような
自分も購入済みだったけどストアから消えた

>>418ならただの宣伝マルチポストなのでさっさとNGしておくように

char text[32] = "count="
sptintf(text, "%s%d", text, 100);


↑これって問題ない？　

オーバーフローを懸念。

snprintf

>>421
sprintf のことだよね？
問題はある。
領域が重なるオブジェクト間でコピーが行われるときの動作は未定義とするという仕様になってる。

それと関数シグネチャを見ればわかるが引数のところに restrict ってついてるでしょ。
その性質上、他の引数がこれと領域が被ってはいけないというサインだ。
まあ引数を使わない関数であれば restrict 修飾されたポインタが指す領域がかぶってもただちに違反ではないが、常識的には渡す以上は使われるものと想定すべきだよね。

>>421
問題ありだ。1行目末尾にセミコロンがないじゃないか
あと、学校の宿題の答えをこんなところで聞いちゃいかんぞ

最近の小学校ではこんな宿題出るのか
末恐ろしいと言うか、頼もしいというか

コンピュータの授業とか普通にあるんだろ？今って
俺からすると羨ましい限りだわ
でもダンスの授業はいらん

元々芸術科目や体育は面倒な存在だし
ダンスはそれらが合わさって一見最強に見えるだけで専門科目に比べれば実は大した内容じゃない
子供は加減の付け方を知らないから物凄い壁に見えるんだろう

1990 年代頃なら中学校でコンピュータの授業はあったがプログラミングがちょっとでも出来るようになるほどではなく使い方に慣れるという程度だったと思う。
ただ、学校に設備や資料はあったから興味があれは詳しくなれるチャンスはあった。
設備をどのくらい解放するかは学校の体制によるだろうけど。

>>427
踊りながら英語でコンピュータを使え

科学 ＋ 5ch

【AI】AIはわずか2時間の対話で人間の性格をコピーできる [すらいむ★]
http://2chb.net/r/scienceplus/1733576027/

コメントに面白いことが書かれている

2時間で初等教育から大学院レベルまで学習完了したら
人間要らなくなりそうだな

>>429
たしか教師がクソすぎて失敗したんだよなｗ

やがて全ての仕事がAIに直結されたロボットによって置き換えられ、人類絶滅。
地球はAIのみが存在する世界になり、真空でもそのまま動くロボットが宇宙征服。

チェックボックスとかラジオボタンの状態を保存したいんだけどなんて調べればええんすの？
現状ウィンドウを破棄する前にコントロールの内容を取得して状態に合わせた変数を初期化ファイルに保存、再起動時に変数に対応した状態に再設定するみたいなのしか思いつかん
冗長になって見づらいだろうし代替案を知りたい

その通りで良いと思います