C言語なら俺に聞け 159

2022/08/04(木) 23:32:27.83

!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

C2x ドラフト
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2731.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言語なら俺に聞け 158
https://mevius.5ch.net/test/read.cgi/tech/1640401906/

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

2022/08/04(木) 23:46:06.88

現時点んでの C2x 最新ドラフトはこっち
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2912.pdf

2022/08/04(木) 23:50:16.33

訂正ありがとう

2022/08/08(月) 01:13:34.41

n3047がC23の投票に掛けられる模様

2022/08/08(月) 01:16:49.11

おっ、こないだの会議の結果が反映されたドラフトが出てたのか。

2022/08/13(土) 08:01:13.53

配列の初期化に変数使えるのはGCC拡張ってマジか・・・
これ↓

int arr[3] = { a, b, c };

知らなかった・・・

2022/08/13(土) 08:05:10.38

>>6
あれ？
-std=c11 つけてコンパイルしてもエラーにならないな
>>6は一応C標準てことでいいのかな？

2022/08/13(土) 09:53:55.13

>>6-7
言語仕様を確認してみたら、変数が静的記憶域期間を持つときは
初期化子に現れる全ての式が定数式でなければならない (変数を含められない) という制限はある。
自動記憶域期間なら初期化子に変数を使っても問題ない。
GCC でもそのような挙動になる。

2022/08/13(土) 09:54:36.52

>>6
staticやグローバルにすると・・・

2022/08/13(土) 10:02:52.43

関連する挙動を色々と試してたんだけど、
GCC では const 付きの変数の挙動が少し C++ 寄りに拡張されているっぽい。

C++ では const 付き変数の初期化子が定数式である場合にはその変数も定数式になるが、
C では単に代入できない変数という扱いのはずなんだけど、
GCC では定数式っぽい振る舞いをする場合がある (全面的に定数式扱いというわけではない) ように見える。

2022/08/13(土) 17:52:01.55

>>9
それが静的記憶域っちゅうこっちゃがなーー

2022/08/13(土) 20:18:21.81

>>11
だからそれを言ってる

2022/08/14(日) 00:23:10.64

もう>>8に書いてあるじゃん

2022/08/14(日) 00:37:06.28

あーなるほどstaticかぁ
お前らありがとん

2022/08/14(日) 08:08:18.99

K&R Cでは配列の初期化子にも同様の制限があって
その理由は合理的だった
その後ある事情で無理が通って道理が引っ込んだ

2022/08/14(日) 11:44:40.04

staticには意味が複数あるのがC言語の挫折ポイントのひとつ

2022/08/14(日) 12:08:31.19

予約語を増やさないという方針自体は互換性を損なわないために真っ当なものだと思うけど、
名前がかぶったら単に一括置換で対処できる程度のことでもあるしなぁ……。

2022/08/14(日) 12:20:02.25

>>16
そんなので挫折するならもっと前に挫折するだろw

2022/08/14(日) 12:34:09.99

挫折自慢大会が開催されました

**ハノン** ◆QZaw55cn4c (ﾜｯﾁｮｲ 41e6-U0U7) · 2022/08/14(日) 13:14:34.32

Scheme 手習い、を挫折しました、いつ再トライしようかしら？

2022/08/14(日) 15:10:21.65

自分の性分に合ったものは気合いを入れなくても割とスルっと出来ちゃったりするし、
そういうところから周りに広げていく形でやってけばいいんでないかな。
業務で必要とかならそうも言っておれんだろうけど。

2022/08/14(日) 16:55:08.09

Kotlinもよろしく

2022/08/14(日) 17:14:45.00

完全な文脈自由文法で設計されていれば、コンパイラも簡単に作れるけどな。
しかし、Javaのその特性は完全に無視され、誰にも気づかれなかった。
お前らも気づいていない。

2022/08/14(日) 21:52:34.16

構文解析だけ簡単でもコンパイラが簡単なわけではないが……。
部分的にでも簡単であるに越したことは無いけどさ。

2022/08/15(月) 06:53:02.58

いや宣言文→実行部のように決まっている文脈ガチガチのほうがコンパイラは作りやすい

2022/08/15(月) 08:31:44.94

今時字句解析とか構文解析で難しいとかないでしょ
それなりのツールもあるからBNF書ければ自動生成できたりするし

2022/08/15(月) 09:21:08.58

>>26
言語仕様のほうも処理しやすいように寄せてきてるからだよ。
パーサジェネレータを前提として設計された言語仕様ならパーサジェネレータで処理しやすいのは当たり前の話。

2022/08/15(月) 09:27:22.60

>>27
難しいって一体どんな言語仕様を想定してるんだ？w

2022/08/15(月) 09:47:41.49

>>28
FORTRAN 77

2022/08/15(月) 10:35:55.74

>>29
字句解析と構文解析を一体でやらないといけないから面倒ではあるけど難しいという程じゃなくね？
そもそも人間にとっても分かりにくい言語仕様を採用するのもどうかと思うが

2022/08/15(月) 11:11:29.28

>>30
今の主要なプログラミング言語はそう (処理段階の分離が極端に難しい仕様には) ならなかったという話をしてる。

だから昔のものから例になりそうなものを抽出しただけで、この頃の知見のまま設計された大きな言語があったら
現代的なツールでも扱いにくいだろうということ。

2022/08/15(月) 11:28:00.05

>>31
だから多少面倒なだけだろ
そもそもスペース無視するとか予約語を識別子に使えるとか人間側にも優しくない仕様ででかい言語仕様とか頭おかしい

2022/08/15(月) 11:39:32.94

>>32
漠然と変だとは思ってたとしても、知見の確立がなかったとしたらそのまま進むしかしょうがないだろう。
まあ、そうなっていない世界でのもしもの話、実際に無かった以上は想像でしかないけどな。

2022/08/15(月) 12:01:53.74

>>33
そもそもFORTRAN77以前でも
DO 100 I = 1. 5
なんて言う「代入文」を書く奴なんてほとんどいなかったわけで知見が確立しないまま言語仕様だけでかくなるとかまずありえんわ
まあ妄想に浸りたいだけなら勝手にやっててくださいな

2022/08/15(月) 12:48:46.30

ほとんどいない笑
たまにはいたんですね？

2022/08/15(月) 13:28:30.95

>>35
タイプミスとか、難読大会とか
想像力ないの？