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/08/07(月) 21:06:32.92

>>385
1バイトごときのために余計なことをしないってのは理解できる理屈だが、不必要な1バイトを確保するってのもそれはそれで無駄に考えさせられてしまう感じがする。
やろうとしていることと合致しないコードなわけだから。
害はないが役に立ってもいないということを確信するのはどういう役に立っているのかを見つけるより難しい。

2023/08/07(月) 21:30:20.59

>>384
ああ、[1]の場合のコード見てたわ、お恥ずかしい。
どっちにしろ[1]の場合もoffsetofかalignof使ってあれこれだね…sizeofじゃ正解ではない…

2023/08/07(月) 22:08:57.23

>>386
どうせmallocは1バイト単位では確保しないので正確なサイズを指定しても構造体一個につき数バイト以上の無駄な領域が確保されることになるし…
この構造体を数万個単位で使うような大規模プログラムで極力ムダを避けたいならmallocは使わず最初に大きなリニア領域を確保してそこから切り分けたほうがいいだろう

蛇足だが経験上こういう構造体を使うときはcopy=malloc(sizeof(A) + strlen(src)); strcpy(copy->a,src);のように使うことが多い
これなら正確なサイズ指定になる

>>387
どっちにしろ君は何か勘違いしてないかな
長ったらしく書くなら-sizeof(int)ではなく-sizeof(char)となる

2023/08/07(月) 22:21:06.53

どんどん蛇足的になってしまってる気はするが

1バイトの加減算ってのはインクリ・デクリの1命令で演算できるし分岐しないし、
アライメント境界を1バイト超えたらバス幅分-1の無駄ができるかもなので
しかも100万個の「3d座標型」とかがその理屈で1個につき7バイト無駄にしたら700万バイトが無駄になるので
たかが1バイトと軽視して良いか否かは、状況によります

で、はちみつさんのちみつな調査に感謝。蛇足で変な事書いて仕事増やしてごめんなさい

2023/08/07(月) 22:28:38.60

でも、ワシは（もしそれが有効だと判断したら）公式なC言語仕様上未定義になるとしても、
伝統的にgccとvcが「独自拡張」として許してきた書き方で
書くよ

もちろん責任者の許可は伺うけどね
ダメと言われたらもちろんやらない

2023/08/07(月) 22:34:55.16

>>388
ちゃんとサイズ確かめた？そんなに簡単なら[]拡張なんて要らないと思わない？

2023/08/07(月) 22:36:31.40

で
時には自分が、あるプロジェクトの最高責任者だったりする訳で
その環境は特定のカスタムgccの特定バージョンを使うしか選択肢がないから無用な心配は意味がなくて
次のプロジェクトではどうせ全部作り直しだったりする

2023/08/07(月) 22:48:24.16

>>391
何を確かめればいいのかね
正確に書いてくれないと答えようがないな
後半個人的には「要らない」ね
誰かが拡張したら使わないとイケないという「強迫観念」を持ってないか？
それは不要なものだよ

2023/08/07(月) 22:52:47.17

>>393
sizeof(A) != sizeof(int) + sizeof(char)

2023/08/07(月) 23:31:53.12

>>394
メンバの配置はきっちりつめるのから
nバイトアラインで飛び飛びにしてるのもあるしね

2023/08/07(月) 23:39:40.36

>>395
一番最後のメンバの後ろにパディングが足されるかどうかが焦点になる
足されないならイージーに引き算すりゃいいんだが…

2023/08/08(火) 07:56:15.14

引き算とか言ってる馬鹿初めて見たわ

2023/08/08(火) 11:03:00.71

複素数使って計算すれば馬鹿にされませんよ？

2023/08/08(火) 20:31:55.04

>>394
意味はわかったけど
君のコードは可搬性がないわけだね
全部作り直しになるのもうなづける
そんなのやってられないｗ

2023/08/08(火) 22:38:48.82

>>399
初歩的な構造体のパッキングルールを理解していたらどうって事無いはずなのだけども…この程度で可読性とか労力とか、そういうレベルの仕事なら使用禁止で良いんじゃないかな。

あと、何か勘違いしているようだけど、[1]だとややこしいけど出来るねって言ってだけで、使うなら[]だよ。c99標準な訳だし。

2023/08/09(水) 00:47:58.70

「-sizeof(int) が正解」とは言えないよ環境による
パッキングルールを変更できる#pragmaもあるから
それは単なる「思い込み」ということになるな

2023/08/09(水) 06:00:17.77

>>399
あなたが「君」って言ってる相手は少なくとも私と私以外の2人以上なので何か誤解してると思う
ここは匿名掲示板なので、想像した人格じゃなくて内容に反応して欲しい

2023/08/09(水) 08:10:28.54

言語仕様知らずに叩いてるんだから無理だろ

2023/08/11(金) 14:52:37.80

質問失礼します
Windowsソフトが作りたく基礎を勉強したのですがここからソフトを作る道筋が見えてきません
SDKを用い制作するということまではわかったのですがそれについて解説しているサイトがなく詰まっている状態です
おすすめのサイトや参考書などあればご教示くさだい

**デフォルトの名無しさん** (ｽﾌｯ Sd2f-SP/C) · 2023/08/11(金) 15:39:30.67

https://dxlib.xsrv.jp/dxfunc.html
http://marupeke296.com/DirectXMain.html

2023/08/11(金) 15:46:47.16

モダンなフレームワークを使った方が良いが
Windows の基礎的な理念というか考え方をかなり平易に
説明したものということだと↓とかが有名だと思う。
http://www.kumei.ne.jp/c_lang/
ただ、古いので実情に合わない部分はある。

Windows には異なる系統の API があって、
現在では COM をベースにした WinRT がモダン API として
整備されているのでそちらを軸にしても良いかもしれない。

2023/08/11(金) 16:09:36.01

SDK使っての開発は30年位昔のやり方なんではないだろうか

2023/08/11(金) 16:11:15.49

>>405
>>406
ありがとうございます
早速進めてみます

2023/08/11(金) 16:12:13.55

＞＞407
基礎しかわからない初心者なものでして、、、

2023/08/11(金) 16:53:28.21

Windows のネイティブなプログラム作りには C というよりは C++ の方がよく使われていたと思うので、C++ も覚えた方が作り易くなるような気がする。

2023/08/11(金) 17:26:57.28

>>407
使えるものは使えば良い
昔の方がシンプル

>>410
MFCやATL/WTLやCOMやQtやwxWidgets使いたいならC++だが
生WindowsAPIとSDKやCOMやOpenGLやtcl/tkとか使うならCで充分
むしろCが標準と言っても良いので勉強用ならC

2023/08/11(金) 17:52:29.73

なるほど。

2023/08/11(金) 17:54:37.84

最初残ろは16ビットアプリだったから、
メモリーモデルやアプリが使用可能なリソースサイズなど
結構管理が大変だった記憶がある

2023/08/11(金) 17:55:37.06

最初のころは

なんて変換するんだよ・・・

2023/08/11(金) 18:22:42.78

勉強目的の縛りプレイじゃなければ最初からCじゃなくC++使う方が良いと思うが。

2023/08/11(金) 18:30:11.06

いまだにCOM ATL DirectX IDL辺りの定義見るとC知識では手に負えないイメージ
C++MFC全盛の時代は本当に嫌いだった
C#でそれらに一切関わる必要がなくなってほんと良かったわ

2023/08/11(金) 18:52:16.19

古いAPIの設計思想が時代に合わないのも多いし、フレッシュな知識を蓄積したほうがいいという意味ではWinRTかな

2023/08/11(金) 19:09:53.39

>WinRTかな
名前が終わってる

2023/08/11(金) 19:10:12.84

DirectXはCでも使える

2023/08/11(金) 19:11:09.76

MFCは糞だから触るな危険

2023/08/11(金) 19:12:06.88

WinRTはないな

2023/08/11(金) 19:17:33.71

とりあえず現在でWindowsアプリのプログラミングを始めるにあたり、C言語というのはやめるべき
悪いこと言わないからせめてC++にしておけ
そして楽に作りたいならC#にしておけ

2023/08/11(金) 19:26:30.18

C でやってみれば (やれるだけの知識を身に付ければ) 低レイヤで何が起こっているのかという具体的なメカニズムを理解できるという意味で悪くはないと思う。
ただ、今となっては日常的にやるもんではない。

2023/08/11(金) 19:26:45.26

C#で.NETにない事をやろうとするとpnvoke知識が必須だから
Cを適当に摘みつつC#でいいんじゃなかろうか
C++はもう時間の無駄
時間が無限にあるならどうぞ

2023/08/11(金) 19:35:56.75

Ｗｉｎｄｏｗｓの動作原理を学びたいなら、ＳＤＫやＭＦＣは良いと思うよ

2023/08/11(金) 19:53:56.21

今のWindowsの最新のUIは全てWinRTの上に構築されている
Githubでソース見れば一目瞭然
完全に今のWindowsの基礎となるAPI
無知というのは罪だな

2023/08/11(金) 19:58:54.93

まさかWinRTでマウント取ろうとする馬鹿が居ると思わないわ

2023/08/11(金) 20:00:58.18

黙NG

2023/08/11(金) 20:32:13.88

>>427
無知乙w
正論にキレるの図w
反応しなきゃいいのにw

2023/08/11(金) 20:35:15.14

>>427
WinRT終わってるとか無いわーw

2023/08/11(金) 21:00:42.88

変なのが湧いてきたね

2023/08/11(金) 23:10:37.93

mallocの戻り値は代入先のポインタ型にキャストして使おうと言ってる入門サイトがほとんどです。
これは正しくなくて、キャスト不要が正しいと思いますが達人の皆さんの意見はどうですか。

2023/08/11(金) 23:16:31.85

void*はキャストしなきゃ使いようがないだろ

**蟻人間** ◆T6xkBnTXz7B0 (ｽﾌｯ Sdd7-38VD) · 2023/08/11(金) 23:37:09.78

C++ならvoid*からのキャスト必須。C言語ならキャスト不要。

2023/08/11(金) 23:43:24.35

現場猫案件。

2023/08/12(土) 00:37:36.88

>>431
害悪はオマエだろ！
WinRTが終わったAPIみたいなフェイクを正したんだよ！
WinUIとかGithubでソース公開されてんだから、ソース見れば一目瞭然だろ！
2度とフェイクを書き込むなよ！

2023/08/12(土) 01:20:09.40

もしかしてWindowsRT(ARM版Windows8)と勘違いしてたりして

2023/08/12(土) 02:14:36.52

WindowsRTは失敗したプロダクトだけど、WinRTは完全にWin32を置き換える為のモダンな基盤APIになった
ちなみにWinRTに関する情報は全然出回ってないな(少なくとも日本では)
MSも直接使うAPIじゃないと考えてるのかもしれない
実際、WinUI3とかを通して使うことになるのだろう

2023/08/12(土) 02:21:43.01

MSは一時的に、DirectXやActiveXみたいにRTを流行らそうと考えてたふしがある
でも、まったく浸透せずにRTに悪いイメージだけが残ったw

2023/08/12(土) 04:30:30.39

ないわ

2023/08/12(土) 11:53:24.11

>>432
型変換とキャストを混同して説明していることがそれなりにある。
それとは別に不要でもキャストすべきかどうかというのは習慣の問題。人にとっての読みやすさは仕様上の要・不用とは別の話なので明瞭な答えはない。

2023/08/12(土) 12:15:02.77

UWPのWinRTでファイルアクセスなどに制約がある場合があって
APIレベルでセキュリティ上の制限があるのかと思ってたが間違いで
他のプラットフォームで呼ぶと普通に色々アクセス出来てしまう

2023/08/12(土) 14:04:01.34

そろそろ他所でやってくれんか
普段Windowsには世話になってるけどUWPの存在には憎しみさえ感じる

2023/08/12(土) 14:18:40.69

>>441
cast という単語には型変換の意味があると思うが?
で、実際にプログラミング言語では型が変換されるから、型変換で良いんじゃないの?

2023/08/12(土) 14:53:08.69

>>444
Ｃの仕様上の意味合いとしてはキャストという用語は構文 (記法) を指している。
括弧の中に型を書いたやつを式の前に置く、あの構文のことね。

キャストを使わない形でも (暗黙の) 型変換が起こることはあるし、
型を変えないキャストも出来る。型変換とキャストは同一ではないよ。

カジュアルな場合では文脈でわかるし、ときには同一視してもいいこともあるけど >>442 の文脈では
構文のことを言っているのか型変換のことを言っているのかで事情が変わってくるので
厳密でなくても良いとは言えない。

2023/08/12(土) 14:54:12.64

>>445
アンカーを間違えた。 >>442 じゃなくて >>432 ね。

2023/08/12(土) 20:19:50.46

「毎日出社したい」わずか3.8％　リモートワーク経験者に聞いた

学研ホールディングスのグループ会社であるベンド（東京都千代田区）は、リモートワーク
経験者を対象に「リモートワークに関するアンケート」を実施した。その結果、半数近くの
人が「週5（フルリモート）」（44.4％）をリモートワークの理想の頻度だと考えていること
が分かった。
次いで「週3～4」（30.7％）、「週1～2」（20.1％）と続き、96.2％の人がリモートワークの
継続を希望していることが分かった。毎日出社を希望する人は、わずか3.8％だった。
出社を希望しない理由は「通勤にかかる時間や体力がもったいない」「子どもの都合で、
リモートワークのほうが仕事と家庭のバランスが取りやすい」「職場の人と毎日顔を合わせる
のはさすがにつらい」といった意見が寄せられた。
　一方、「コミュニケーションが取りにくくなる」「出社しないとできない業務がある」
「たまには出社もいい気分転換になる」など、完全リモートだと不都合だという声もあった。

2023/08/12(土) 22:15:14.90

>>445
冗長 int *p = (int *)malloc(400);
簡潔 int *p = malloc(400);

ということを言うつもりで書きました。

2023/08/12(土) 22:54:57.04

>>448
仕様上は暗黙の型変換が適用される場面。
キャストを書かなくても型変換はされることが保証される。

ただ、 >>434 で言及されているように C++ ではキャスト必須なのでそれに合わせる (ことで C++ としてもコンパイルできるようにする) ほうが好ましいという考え方もある。これが暗黙に変換できてしまうのは良い仕様とは言えないのは確かだからより厳しいルールの C++ に合わせるのも一応の合理性はある。

誤解の余地もない (と思う) ので私はキャストを書かない派なのだけど、以前にツイッターかどこかのアンケートで見た感じでは拮抗してて、どちらが優勢というわけでもなかった。

2023/08/13(日) 11:59:59.00

int *p = (int *)malloc(400);
冗長ではないよ

2023/08/13(日) 22:00:40.70

C++でnewではなくmallocをあえて使う理由って何かあるのかな？

2023/08/13(日) 23:29:06.42

>>449
くわしくありがとう。そういう見方もあるのですね。
アンケートで拮抗というのはわかる気がしていて、その理由が入門書やサイトにあるのではと思うのです。

>>450はなぜそう思いますか。

2023/08/14(月) 00:14:53.81

void *が無かった頃はmallocもintやchar *を返していた時代がある
処理系渡り歩いてきた老害ほどmallocでキャストしたがるだけだろ
大した話でも何でもない

2023/08/14(月) 00:21:55.24

可読性を上げるためでもあるのでは？

2023/08/14(月) 00:30:57.60

>>454
可読性が上がるだろうか？少なくとも >>448 のように変数の型がその行に書いてあるようなケースでは
誤読の余地は全然ないように見えるので同じ情報を重複して書く意味が感じられない。

2023/08/14(月) 00:38:36.06

まあ確かに型がすぐ分かる場合は意味ないな。

2023/08/14(月) 09:03:40.40

>>448
組織(会社とか)のコードだと、どんな水準の人がメンテするか分からないので、冗長を採るかな。

> 冗長 int *p = (int *)malloc(400);

2023/08/14(月) 09:28:55.46

この話が一番冗長だtoomou

kanjidenakunatta

2023/08/14(月) 10:36:19.28

>>452
K&R の第二版 (日本語版) でもキャストは必要だと書かれているんだよなあ……。
本の最後に仕様をまとめているところでは暗黙に変換されることも言及されているのでおそらく改定漏れなだけなんだろうけど。
かなり長く定番の入門書だったのでこの本の影響も大きいと思う。

2023/08/14(月) 11:55:47.09

暗黙に変換って、プログラム書いてる本人の意図通りなら良いんだけど
意図と違った変換するとやっかいだな

2023/08/14(月) 13:20:28.84

ここがC言語スレだと思い出して欲しい

2023/08/14(月) 13:23:53.19

Cの暗黙の型変換なんて高が知れてるだろ

2023/08/14(月) 14:02:18.88

昔のmalloc()ってchar*とか返してた気がするな
最初っからvoid*って有ったのだろうか？

2023/08/14(月) 14:16:28.68

すべての戻り値はintである
ポインタかどうかは書いた人間がが判断する

2023/08/14(月) 15:03:08.99

(void)main(void)

**蟻人間** ◆T6xkBnTXz7B0 (ｽﾌｯ Sdba-F9Mj) · 2023/08/14(月) 15:17:16.05

>>464
AIが混乱するようなことを言わないでほしいも

2023/08/14(月) 16:43:05.60

>>464
それ LLP64 でも同じこと言えるの？

2023/08/14(月) 17:46:44.25

>>464
それはB言語のようなミニ言語やBLISSやアセンブラのようなシステム記述言語でよくあるやつだな。
そういう血塗られたルーツを持つCが普及してしまったのがこの大災害の原因ではあるが。

2023/08/14(月) 18:03:50.08

今は血を流さずに戦争ができます

2023/08/14(月) 18:07:41.52

ポインタじゃない構造体の代入はメモリコピーで、intじゃないよね

2023/08/14(月) 18:22:17.15

>>467
それですよ。

あと、実際の案件で
メモリバスが32より大きい環境でも、64ビット全部が使われてるとは限らないです。
あるビットにこう入ってたら40ビットのxxメモリ空間を指し、あるビットにこう入ってたら48ビットのyy空間を指す、とか
ポインタ値にも複数の種類がある（ように設計する事がある）

何が言いたいかというと全部intだなんてのは、分かってない証拠

2023/08/14(月) 18:39:04.59

可変長のポインタって、すごいな

2023/08/14(月) 18:42:29.14

昔は関数から戻り値として構造体が返せなかった
MSか勝手に実装した

2023/08/14(月) 18:47:31.20

返せなくても困らなかったけど
例えばポインタで返しているAPIはいくつかあるだろうし
呼出時に渡す構造体で返すやり方も普通にある（こちらの方が多いかも）

2023/08/14(月) 21:33:10.14

8051風のMCUにはメモリ空間が複数種類あるものがあって、どのメモリ空間をポイントするかによってポインタのサイズが1byteか2byteかに分かれるというのがありました。

2023/08/14(月) 22:08:33.35

>>473
K&R の初版 (1978 年) の段階では
構造体を関数の返却値に出来る仕様ではなかったのは確かだが
その制限は将来的に削除されるとも書いてある。
構造体を返せるようにするのは設計者の計画の内だ。

最初に実装したのが誰なのかは知らんが「勝手に」とは言えないだろう。

2023/08/14(月) 22:12:43.60

えてして実装が先で、規格になるのは後
というのはよくある話

2023/08/15(火) 18:53:02.89

規格が先行することなんて無いでしょ
出来レースみたいな例外を除けば

2023/08/15(火) 19:27:12.11

仕様もクソもANSI Cが出来るまでCに仕様だの規格だの自体がなかったよ
K&Rにしても当時はあくまで標準って位置づけだったし、各処理系で互換性のない部分が結構ある時代だった
そもそもK&Rって本自体Cの言語としての仕様を示すための本じゃなくて、Cの使い方を説明するユーザーガイド的な書籍だしな
大体、当のデニスリッチーからしてK&R初版の時点で自分のコンパイラではすでに構造体のやりとりを実装させてたんだから

2023/08/17(木) 17:55:25.45

K&Rはバイブルってだけ
宗教に喩えて開祖だか教祖だかが著したもの

2023/08/17(木) 17:57:11.47

バイブルに従え

2023/08/17(木) 18:38:44.78

C言語ルター派

2023/08/17(木) 19:50:44.50

般若心経

2023/08/17(木) 20:29:24.71

>>481
天国が来るだろう(構造体の戻り値)って書いてあるんだから天国の到来を疑ってはいかんだろｗ

2023/08/19(土) 16:55:05.41

剣かK&Rか貢納か