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

**デフォルトの名無しさん** (ｽﾌｯ Sd8a-rFCo) · 2023/08/04(金) 16:09:46.38

>>>345 >>>346 即答ありがとうございます
自分はまったくそこまで考えてstlrenを使ってませんでした。ありがとうございます。勉強になります

2023/08/04(金) 16:25:43.11

そこまで考えてというかポインタ/配列添え字が 0 から始まるだけの話でな
　1文字目 = (オフセット)0
　2文字目 = (オフセット)1
:
　n文字目 = (オフセット)n-1

他所言語（特に古めのBASIC) だと配列の添え字は 1から始まるのが自然だから
その感覚のままだと　およよ？　ってなる

2023/08/04(金) 16:33:03.37

COBOL, PL/I, RPG, FORTRAN, BASIC, R, Lua, Julia は、1で始まる

2023/08/04(金) 16:45:56.55

BASIC はバリエーションが多いよ。
0 と 1 を切り替える機能があるやつを知ってる。

2023/08/04(金) 22:18:35.44

>>341
そのやり方だとapple審査通らないのでは？

2023/08/04(金) 22:23:16.57

環境はwebkitでvm自体dlしてくるから問題ないということなのか…

2023/08/05(土) 14:06:37.50

>>349
Pascal もよろしく

2023/08/05(土) 21:43:38.19

>>353
Fortranは添字の開始値を指定しない場合は1から始まり、添字の開始値を指定する場合は任意の整数
（負も可）を指定できるが、Pascalは添字の開始値指定が必須で任意の整数（負も可）を指定できるから、
1から始まるとは言えない。

2023/08/05(土) 22:05:05.59

>>350
ああOPTION BASEかあ
N88BASICの頃からあるが使ってるの見たことない

2023/08/05(土) 23:14:06.26

>>354
そういやそうだった。忘れてた。

2023/08/06(日) 12:09:56.49

今時はExcelのセルをCellsでアクセスしたり配列に代入した場合だけ1オリジン固定でちょっと困る
歴史的経緯というよりExcelのCOMオブジェクトの仕様なんだろうけど

2023/08/06(日) 13:13:28.45

配列って
array + sizeof(*array) * index
だから、0からの方が理にかなってると思う
1からの場合は、実行時にアドレスを割り出すときに絶対1引いてるよね…
そこまでしても人間の直感に合わせたかったのだろう

2023/08/06(日) 13:25:15.07

１引いているのはあくまで内部的なもの
それこそ人間の直感に合わせたインターフェイスとコンピュータの都合の良い情報に相互変換するのがプログラムじゃなかろうか
0からのほうが分かりやすいと思うのはプログラマだからだろうし
10個のデータの最後のインデックスは10というのは添え字で考える場合は分かりやすいしね

2023/08/06(日) 14:09:12.01

先頭をゼロと呼ぶか1と呼ぶかならまだマシよ
音楽なんて先頭要素を1と呼ぶだけじゃなく、要素間の差がない事まで、ゼロじゃなく1と呼ぶ

現代人からするとどう考えても頭おかしいが、仕方がない。ゼロの概念がなかった時代から定義が変わらず続いてるらしい

2023/08/06(日) 14:15:40.68

Cはゼロに限らず何もないを示すvoidが無い頃は全部intでやってた時代もあるんだよ
頭おかしいな

2023/08/06(日) 14:37:12.68

voidが何もないことを示すならvoid*の存在のほうが気になる

2023/08/06(日) 14:59:14.25

void だけ特殊な型と考えるしかないのではないかな。大きさが0ビットの型と考えても良いのかも知れないが。

2023/08/06(日) 15:50:27.26

sizeof(void) → 1 だな
これって正式な仕様なのか分からんけど

2023/08/06(日) 16:40:17.07

それgccなんかの独自仕様のはず。void*をバイト単位で計算できるから便利なんだけどね。

2023/08/06(日) 17:35:17.48

それは気持ち悪いな

2023/08/06(日) 17:46:22.79

言語仕様上は void は不完全型とする扱い、かつ sizeof に不完全型を与えることは出来ない。

2023/08/06(日) 17:48:27.27

gccだとsizeof(関数名)も１なんでしょ
明らかにただの手抜き

2023/08/06(日) 17:52:12.98

仕様上の問題は置いておいて
1として扱うと何か良いことあるんでしょうか？

2023/08/06(日) 17:56:04.37

未定義な動作は規格として規格が何ら要求を課さないことを意味するが
但し書きの中に「文書化された環境に特有な方法で処理してもよい」ともある。

GNU C のドキュメントには void と関数 (関数指示子) の大きさについて記述がある。
https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html
これも規格が認める正しい動作のひとつ。
それはそうとして処理系に固有の挙動に依存するのを避けるに越したことは無いけど。

2023/08/06(日) 18:03:13.82

>>369
>>365にも書いたけど、演算するのにいちいちchar*などにキャストする必要がない。

2023/08/06(日) 18:10:14.29

void* は演算させないという意思表示なこともあるんで
演算できることが良いわけでもないんだけどね。

2023/08/06(日) 18:29:53.89

どんな用途があるかな？デリファレンス先にアクセスできないってだけで十分な気もするが。

2023/08/06(日) 18:36:51.14

任意に渡ってきたポインタ間の距離？

2023/08/07(月) 01:08:17.44

アレじゃないかな？メリットあるとしたら

【struct に含めたメンバーは、サイズゼロはダメ】っていう仕様があったかと思う。
正確には【structの違うメンバーが同じアドレスになったらダメ】だったか

----
以下は蛇足

ただサイズゼロだめってのは例外があって。
structの末尾メンバーでchar[] だか char[0]ってのが、確かC99あたりでアリになった気がする。

これは…それまでも使われてたテクで
【structの最後に char [1] のメンバーを置いて、実際にはメモリ確保の時structのサイズ+可変長部のサイズでメモリ確保し、最後のメンバーを使ってstructのサイズを超えてアクセスする】という慣用句があって、
それの目的で
C言語公式仕様風では char[1] と書き
確か昔は gccだとchar[]
vcだと char[0]
ていう書き方してた。（gccとvcは逆だったかも知れない）

のが、公式仕様でもサイズゼロokになった…という話だったかと。

2023/08/07(月) 01:23:44.93

あ、メリットの言い方をすると

処理系内でstructのサイズ計算を実装するにあたって、あらゆる型がサイズ1以上である事が分かっていれば、合算処理を合理的に実装する事ができる
…よね？

2023/08/07(月) 08:18:18.04

意味不明
メンバーにvoidを含められたとしても参照すればエラーになるはずなので使いようがない
(void*はもともと正しいサイズを持つ)
unionで似たようなことはできる

2023/08/07(月) 09:11:24.17

>>375
サイズゼロをOKとすると言ってしまうと語弊があると思う。
仕様上の理屈だと「不完全型を指定できる」だし、そうした場合の動作は
いくつかの特例で成立していて「長さ 0 の配列」は現れない。

sizeof などでは「フレキシブル配列メンバは無視される」だし、
メンバにアクセスするときは

> 置き換えられた配列が要素をもたないとき，それはただ一つの要素をもつのと同じ規則で動作する。
> しかし，その要素にアクセスした場合，又はその要素を一つ越えたポインタを生成した場合，
> その動作は未定義とする。

とあって、長さ 1 として扱うけど要素にはアクセスするなという回りくどい言い回しになってる。

2023/08/07(月) 10:17:41.09

>>375
typedef struct { int x; char a[1]; } A; A *p = (A *)malloc(sizeof(A) - 1 + N);
typedef struct { int y; char b[]; } B; B *q = (B *)malloc(sizeof(B) + N);
typedef struct { int z; char c[0]; } C; C *r = (C *)malloc(sizeof(C) + N);
かな

2023/08/07(月) 10:19:25.16

>>378 の主張だと
typedef struct { int y; char b[]; } B; B *q = (B *)malloc(sizeof(B) - 1 + N);
でなければならないのかな

2023/08/07(月) 11:05:26.04

>>379
配列の大きさとして 1 を指定して可変長のように扱うやり方については
ちょっと不明瞭なんだが仕様に厳密にいうと準拠してない方法だと考えられている。
https://c-faq.com/struct/structhack.html

配列の大きさが 0 より大きくなければならないということについては
例外を見つけられないのでどこであろうと 0 を指定したら未定義と解釈していいと思う。

GNU C では構造体メンバの最後の配列要素に 0 を指定した場合は
C99 でフレキシブル配列メンバにしたときとほぼ同じような扱いになることがドキュメント化されてる。
https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
つまり GNU C では 0 を指定していいわけだが……結果が同じならあえてやる必要もないな。

GNU C でも構造体の最後の要素を除いて配列の大きさに 0 を指定するのは (可能だが) 推奨されていない。
アクセスした結果は未定義なのでなんの役に立つのかようわからん。

2023/08/07(月) 11:36:51.88

>>380
-1する必要ないな
１バイト程度なら余計に取っても害はない

2023/08/07(月) 14:20:51.17

>>382
そういういい加減な見積もりは感心しないな
それに、この場合は-sizeof(int) が正解だと思う

2023/08/07(月) 14:26:13.65

>>382-383
どっちも間違い。この場合は -1 をしてはいけない。

2023/08/07(月) 20:36:36.16

>>383
いい加減なのではなく無駄なことに神経を使わないのがプログラマの秘訣だ
それに他人が見て「この-1はなんだろう？」と無駄な思考時間を取られる可能性を考えたら百害あって一利なしだ

>>384
よく見たらデタラメだな
すまん

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