C言語なら俺に聞け 162

2023/10/30(月) 17:13:00.82

!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言語なら俺に聞け 161
https://mevius.5ch.net/test/read.cgi/tech/1682053520/

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

2023/10/30(月) 17:30:23.87

2get

2023/10/30(月) 17:31:34.22

C23 の最新ドラフトは N3096 に更新されてるでよ
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf

2023/10/30(月) 19:05:35.74

>>1

乙です

2023/10/30(月) 19:40:56.11

いまどきPlain Cが使われる状況なんて限定的なんだから
高級アセンブラとして堂々としてればいいんですよ

2023/10/30(月) 20:35:57.87

トッピングは何になさいますか？

2023/10/30(月) 21:04:03.03

リモートワーク制度が削減・廃止されたら「転職や別案件を探す」が4割--
「Offers」登録者調査

ITエンジニア／デザイナーの副業・転職サービス「Offers」を提供するoverflowは、
同社が運営する「Offersデジタル人材総研」にて「リモートワーク実態調査2023」
を公表した。
これによると、リモートワークになり、5人に1人が引っ越したと回答した。そのうち、
現職でリモートワーク制度が削減・廃止された場合、「転職や別案件を探す」という
回答が44.0％にものぼった。一方「会社と交渉する」という回答は40.0％、
「引っ越さず受け入れる」が12.0％となった。
さらにリモートワークを希望している理由として「通勤時間が無駄だと感じている」が
87.7％でトップとなった。このほか「個人の時間ができる」(62.3％)、「副業を続け
やすいから」(39.6％)、「子育てができる」(35.8％)と続いた。

2023/10/31(火) 09:59:32.82

前スレではちみつさんが書いてくれたリンク見ました。thx
https://go.dev/tour/flowcontrol/13

曰くGOの defer は
deferred function calls 遅延関数呼び出しで、関数脱出時にlast-in-fast 順で呼ぶもの

とすると、C言語でdeferの仕様追加要求は却下すべきです。リンクリスト1個作れば済む話で、実際そうしてる人も多数いるだろうに、既存プログラムでdeferというシンボルを使ってるのをコンパイル通らなくしてまで仕様追加するのは利益が小さすぎる。

エラー処理で使うかは、直接関係ないですね。そうしたきゃすればいいけど、私は読みやすいコードとは思わない、です

2023/10/31(火) 12:23:13.16

>>8
＞関数脱出時にlast-in-fast 順で呼ぶもの
＞
＞とすると、C言語でdeferの仕様追加要求は却下すべきです。

この「とすると」からの繋がりが意味不明。

>リンクリスト1個作れば済む話で、

だから何？
「却下 *すべき*」の理由になってない。
採用するほどでない、なら理解できる。

> 既存プログラムでdeferというシンボルを使ってるのをコンパイル通らなくしてまで仕様追加するのは利益が小さすぎる。

ここでのdeferは機能についての名称として使ってるだけで、そのままの文言じゃないことを理解できてないみたいだ。

2023/10/31(火) 15:34:02.36

>>9
話が通じてないと思います
C言語の建設的な議論なら応じたいけど

2023/10/31(火) 15:38:26.62

ブログ立てて、そこでやれ

2023/10/31(火) 15:39:17.26

>>8
どうせコンパイルオプションで無効にすれば使えるだろ

2023/10/31(火) 16:18:39.83

>>10
おまえの感想 >>8 のどこが建設的な議論よ？

2023/10/31(火) 16:24:39.17

ボクの考えた最強のC言語を語るスレはこちら
【超高速】C/C++に代わる低級言語を開発したい 8
http://mevius.5ch.net/test/read.cgi/tech/1345730580/

2023/10/31(火) 16:36:27.63

deferは(素のものをじゃなくてもう少し高機能な)プリプロセッサで対応出来る
breakやreturnの直前にdeferの内容を全部コピーしとけばいいだけ
まぁそれ言い出すと、C++をCに変換するプリプロセッサが有れば全て解決だがなw

2023/10/31(火) 16:37:42.80

ただのどこかのオッサンの意見が気に食わんなら別にそれでもいいよ…

各自自分の考えを語ればいいじゃん、そんな食いつくくらいならなんか一つくらいは「自分のアイデア」あるんでしょ？何もないの？

2023/10/31(火) 16:39:39.94

>>13
既存の「正しいプログラム」が「正しいプログラムであり続ける」

そんなにおかしいことかね

2023/10/31(火) 16:43:21.14

既に進行中の「建設的な議論」をご用意しました
以降の議論はこれを前提として積み重ねていただくようお願い申し上げます
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2895.htm

2023/10/31(火) 16:43:26.09

既に進行中の「建設的な議論」をご用意しました
以降の議論はこれを前提として積み重ねていただくようお願い申し上げます
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2895.htm

2023/10/31(火) 16:57:17.68

>>19
なんか、機能はともかく見た目はだいぶ汚いコードになるね

2023/10/31(火) 17:12:55.99

>>17
全然おかしく無いよ。
互換性は非常に重要。

でもおまえは新しい機能は追加するなって言ってるだけだよね。
おまえの言い分だとプロトタイプ宣言必須になるのは、過去の「正しいプログラム」が正しくあり続けることできないから「却下すべき」案なんだよな。

2023/10/31(火) 17:17:03.54

>>21
プロトタイプ宣言とK&Rスタイルの関数定義がごっちゃになってるわ。
>>21 は回線切って首吊れば。

2023/10/31(火) 17:41:26.94

>>19
俺はGOで組んだことないからそこに書かれてる処理系依存のtry/finallyのが馴染みがあるしスマートに見えるわ
キモい輩って世界中に居るんだな

2023/10/31(火) 17:59:35.29

>>23
君は中傷せずに会話できないのかね？

2023/10/31(火) 21:23:39.92

21 と 22 のワッチョイとIDが同じで表現が口汚いのはどう解釈したらいいの？私には難しくて分かりませぬ

2023/11/01(水) 03:27:47.22

いつもの復オジωωω
スルー決定ωωωωωωωωω

2023/11/01(水) 07:56:22.02

容認→警告→禁止推奨
となった仕様が幾つあったか・・・。

2023/11/01(水) 09:43:55.98

言語の設計思想と立ち位置考えれば手を入れる必要ないでしょ
細かいのはあるにしても関数プロトタイプの導入、データ型の追加、stdioのセキュリティ強化くらいでCとしては充分
構文追加とかバカすぎてANSI Cもまず取り込まんよw

2023/11/01(水) 12:36:29.63

>>28
＞細かいのはあるにしても関数プロトタイプの導入、データ型の追加、stdioのセキュリティ強化くらいでCとしては充分

その挙げ句MISRA-Cみたいなのがでてくる。

＞構文追加とかバカすぎてANSI Cもまず取り込まんよw

C23の属性とか知らんの？

2023/11/01(水) 13:21:32.97

c23だと属性以外にも
enum Colour : char {
Red,
Green,
Blue
};
とか
auto i = 123L;
とかも構文変更になる
constexprもコンパイラにとってはかなり大きい
文字列のハッシュ値の計算とか、コンパイル時にCのコードを実行できる

2023/11/01(水) 13:30:10.50

clangとかはconstexprを使わなくても、最適化で勝手に整数に置き換わってるとか普通に有るけどねw
constexprはそれを確実に保証出来るので、精神衛生上良い

2023/11/01(水) 15:17:19.83

>>30
C23 の constexpr は関数には付けられない。
高度なコンパイル時計算をするものではない。

2023/11/01(水) 17:07:45.92

>>32
なるほど！ちょっと中途半端な状態なんだな…

2023/11/01(水) 17:37:30.95

C++ の const 指定は初期化子が定数 (定数式) なら指定が付けられた変数も定数になるという規則なんだが
C の const は単に書き換えが禁止されるだけで定数になることはない。
(処理系の拡張によって一部の状況で定数扱いされることはある。)

C で定数を作ろうとすると #define を使うか enum を使うかしかなかったので
定数を定義するための直接的な方法として constexpr を導入しようという判断は納得できる。

定数を定義するまともな方法がないってのは C の明らかな欠陥なので
それを改善するという話でしかなくて、
コンパイル時計算を推進する野心の始まりってわけではないと思う。
なので constexpr については (遠い将来はともかく現時点では) これで完了。
中途半端ってこたぁないというのが私の感覚だな。

2023/11/01(水) 21:28:22.72

気に入らないって理由なの？

2023/11/01(水) 23:56:27.24

書き換えが禁止されても定数ではないとはこれいかに…
ここでいう定数はコードに直接埋め込まれる値ということだろう
ただ、C++もstatic constにしないと定数にならないと思ったけど、 constだけだとちゃんとメモリが確保されてると認識してたな

2023/11/02(木) 01:38:41.62

言語仕様上の用語としては定数は定数が要求される箇所に書くことが出来るもののことだよ。
単純な例で言えば、↓これは C++ ではアリだが C ではダメ。 (clang のデフォルトだと通してしまったりもするようだが……。)

const int foo = 1;

enum bar {baz = foo};

int main(void){}

もちろん最適化によって効率的な扱いがされやすくなることも多いにせよ、直接には求められてない。
定数であってもアドレス演算子は適用が可能だし、あくまでも変数なので見かけ上はメモリ上にある。

C++ で static const にしないと定数にならないというのはデータメンバのとき。
普通のデータメンバはオブジェクトを生成するときまで初期化されていないことになっているので
コンパイル時には確定できない。

2023/11/02(木) 09:19:48.35

const int foo = 1;

char hoge[foo];

int main(void){}

**デフォルトの名無しさん** (ｽﾌｯ Sd33-IqBQ) · 2023/11/02(木) 10:39:43.14

2-pass コンパイルを実装してほしい

struct Fuga;
struct Hoge {
　struct Fuga *fuga;
};
struct Fuga {
　...

こんなのとはおさらばしたい

2023/11/02(木) 10:41:08.08

そういう配列宣言でdefine使わないとどういうメリットがあるの？

2023/11/02(木) 12:23:28.61

>>40
デバッグ時にシンボル表示できる。

2023/11/02(木) 15:51:31.06

もしかしてそれって、C言語の仕様じゃなくてデバッガとかビルドシステム側の機能改善でできそうって気がしませんか？

デバッガが読んで参考にできるかもしれない情報の豊富さの、なんとなくの並び
↓
■実行形式にシンボル情報がない
■実行形式にシンボル情報がある
■ソースコードがあるけどデバッガはビルド情報知らない
■ソースコードがありデバッガがビルドの情報も知ってる

clang とかLLVM界隈ってそういう情報（どういう？ビルド時しか分からん情報というか？）をうまく使おうぜ方向を目指してる気がします、知らんけど

2023/11/03(金) 00:15:50.32

その例だとデバッグ時に数字で表示されたほうが安全じゃないか

2023/11/03(金) 08:01:57.68

>ソースコードがありデバッガがビルドの情報も知ってる

両方持ってるのは本物のプロと練習集の初心者素人と両極端に分かれそう

2023/11/03(金) 09:53:21.84

何言いたいんだか全くわからんが

2023/11/03(金) 10:12:48.61

生涯修行僧

2023/11/03(金) 11:32:32.93

>>42
当然だけど規格の話じゃないよ
気がしませんかっていうかコンパイラとデバッガは何十年も前からそうやって連携してる

2023/11/03(金) 11:34:06.16

>>43
数字で表示されないと具体的に何が非安全だと心配してるの?

2023/11/03(金) 21:59:08.35

次に実行するコード
＞hoge[2] = 0;
となった時に
char hoge[foo];
と表示されてると次にfooの値を探すので二度手間
char hoge[1];
と表示されてれば一度ですむ

2023/11/04(土) 00:06:31.86

>>49
何のためにシンボル使うのかわかってないな。
実際の値と値の持つ意味について考えたほうがいいぞ。

2023/11/04(土) 00:27:05.12

哲学には興味ない
なんのためにデバッガ使うかわかっているので充分だ

2023/11/04(土) 02:19:34.08

>>51
なんだ実際のデバッガ使ったことないのか。
普通はシンボルだけじゃなくて値も表示するんだが。

2023/11/04(土) 09:05:55.97

ずいぶん安い煽りに転じたな
表示される情報は最小限のほうがいいんだよ
仕事で使っていればそうなる

2023/11/04(土) 10:09:07.16

自分はデバッガ使う段階なら定数は具体値が出てくれた方がいいです

クロスコンパイル環境の構築からとか、Cならではの現場を辿って来た人と、今どきのGUIのデバッガが前提の人では話は合わなそう

マウスかざせば済むじゃんと思ってるのでは

2023/11/04(土) 11:08:29.93

>>43にアンカうったら>>49で手間がどうこうって返ってきたんだがそういうのを安全って言うのか??
個人的には>>52と同感でマクロにしてもenumにしてもシンボル・値両方確認出来るもんだと思ってたから
どんな環境を想定して言ってるのかちょっとよく話が掴めないな

**デフォルトの名無しさん** (JP 0H09-q9sc) · 2023/11/04(土) 11:41:50.34

gdbなどのデバッガー使っていれば変数名と型と値は全て表示される
必要であれば配列は全ての要素を展開して表示も出来るけどな

2023/11/04(土) 11:48:12.60

printfでOK

2023/11/04(土) 12:21:19.50

シンボルの方が意味が判って良いけどな
「マウスかざせば良い」はその通り
場合によっては watch 式

2023/11/04(土) 13:42:18.42

デバッグ段階で意味がいるのか？

2023/11/04(土) 13:50:23.07

デバッガもその設計思想によるだろう。
ソースレベルデバッグなら言語の評価モデルに一致するのが自然だと思う。
そうなるとシンボルのほうが主役で、評価されれば値になるし一部は事前にわかる場合もある。

バイナリ寄りのデバッガなら
シンボル情報 (デバッグ情報) を扱えるものであってもまずそこにあるのは具体的な値であって、
値のほうをメインに見せる (シンボルは補助的な情報) のが筋に思える。

2023/11/04(土) 14:07:46.76

>>53
お前はアドレスさえわかれば関数名も変数名も不要なんだろうな。
俺はソースレベルデバッグを想定してたけどお前は違うの？

2023/11/04(土) 14:20:50.41

>>54
Cのソースレベルデバッガはgdbとそのラッパー(dddとかKDEのkdebug)しか使ったこと無いな。
お前は何使うの？gdb以外のデバッガにはちょっと興味あるかも。

あと、いつのまにかデバッグの話にすり変わってるけど、元は >>40 で *コード書くとき* の話だからな。
>>41 のせいだな。

2023/11/04(土) 15:58:28.43

例の人ですか？

2023/11/04(土) 19:42:10.24

>>62
スレを私物化してないか？

2023/11/04(土) 21:41:26.73

Cは単純だからぽいんた辺りで躓かない限り特に疑問は生まれずスーっと大脳皮質に浸透していく
それに比べて自称モダン言語の気持ち悪さよ
Cが無かったらプログラミングなんてやってなかったろうな

2023/11/04(土) 21:47:47.71

Cも関数ポインタとかたいがいきしょいぞ

2023/11/04(土) 21:53:04.57

Cの関数ポインタはそれ以上でもそれ以下でもない
セキュリティが緩い頃は関数ポインタを駆使すれば関数型言語で言う所の関数のファーストクラスも実現できた
この時やはりコードとデータは分かれているべきと判りみ
と同時にオブジェクト指向は間違った思想と気付く

2023/11/04(土) 21:57:40.47

少なくとも宣言については無茶苦茶な文法だけどな。

2023/11/04(土) 22:08:52.30

C++になると更にきしょいメンバ関数ポインタがあるが

2023/11/04(土) 22:36:43.09

#include <iostream>
using namespace std;
struct Hoge {
int hage_;
int mage () const {return hage_;}
};
void func (const Hoge &obj, int (Hoge::*func) () const) {
cout << (obj.*func) () << '\n';
}
int main () {
void (*f) (const Hoge &, int (Hoge::*) () const) {&func};
Hoge hoge {10};
(*f) (hoge, &Hoge::mage);
return 0;
}
きめぇ

2023/11/05(日) 00:14:17.78

次の仕様拡張で関数配列が導入されます（嘘）

2023/11/05(日) 10:34:57.51

>>59 とか
>>60 の後者の人とかは
ゲーマーか逆アセか改造チートでもしてんのかなと思う

2023/11/05(日) 10:45:42.91

定数はともかく変数の値の変化を監視するとなれば話は変わりますよ

2023/11/05(日) 10:52:46.61

>>66
単に機種依存なくしてユニバーサル化したアセンブラだからキモいも何もない
感覚的に受け付けないという方はもうすぐAIで自然言語でプログラムできるようになるからそれまで待てばいいじゃん

2023/11/05(日) 11:02:20.21

>>70
こう描けばそこまでキモくない
#include <iostream>
using namespace std;
struct Hoge {
int hage_;
int mage () const {return hage_;}
};
void func (const Hoge &obj, int (Hoge::*p) () const) {
cout << (obj.*p)() << '\n';
}
int main () {
void (*f) (const Hoge &obj, int (Hoge::*p) () const) = func;
Hoge hoge {10};
f(hoge, &Hoge::mage);
return 0;
}

2023/11/06(月) 13:51:35.97

>>75
using使えよ

2023/11/08(水) 13:50:08.70

C++の話はスレチ

2023/11/08(水) 19:54:11.21

その言葉が聞きたかった

**あぼーん** · NG

あぼーん

2023/11/12(日) 08:32:02.96

>>79
おー、これはワクワクするな

2023/11/12(日) 08:34:12.27

>>80
アホ！
１レスくらい間にはさまないとリアリティが出ないだろｗ

2023/11/12(日) 08:51:33.78

ここまで自演

2023/11/13(月) 22:12:34.37

はじめてのCってタイトル狙ってるよね？

2023/11/14(火) 12:53:07.86

なんかドキドキする💗

2023/11/14(火) 15:40:13.41

>はじめてのC
数十年前からの定番ネタだよね・・・今の中年向けの・・・。

2023/11/14(火) 15:56:04.92

お前らはAの経験もないだろ

2023/11/14(火) 17:17:03.46

小さく投げAするときも左利き。

2023/11/14(火) 17:23:51.01

消えたD言語もｗ

2023/11/14(火) 17:24:41.49

APLは経験ないな

2023/11/14(火) 17:26:26.82

魔球は魔球はハリケーン♪

2023/11/15(水) 02:42:58.51

>>90
あなたの年齢は50歳以上ですね。

2023/11/16(木) 19:17:29.74

Cタ「バルス！」

2023/11/16(木) 20:52:49.80

C名「歌舞伎町の女王」

2023/11/18(土) 16:08:05.16

今はABCって言っても通用しないよ

2023/11/18(土) 17:12:35.80

>>94
音階に倣って「イロハ」だったりするのかな。
プログラミング言語ハとか、ハ++とか、ハ長調とか。

2023/11/24(金) 17:31:57.03

三等車か

2023/11/25(土) 04:21:32.09

Cの関数ポインタに慣れてしまってたんなに奇天烈に見えてたのに今じゃ可愛く見える

2023/11/25(土) 04:36:14.81

　 ∧__∧
　(´∀｀)
　 (⊃⌒*⌒⊂)
　　/_ノωヽ_)

2023/11/25(土) 10:00:22.54

目標をせんたーに入れてスイッチ

2023/11/27(月) 08:24:12.52

左辺値と右辺値のことがよくわからない
char *cp = "abcdefgの"abcdefg"は値を変更できないのに、
char cp[] = "abcdefg"の"abcdefg"は値を変更できる

2023/11/27(月) 09:01:26.52

>>100
それは左辺値/右辺値とは関係ない。
「リテラルを書き換えようとしたら未定義」というルールが関与してる。

前者の場合は文字列の場所を示すアドレスが cp に格納されているので
cp が指す先というのは文字列リテラルだが
後者の場合は確保された配列を初期化子の文字列で初期化するという理屈なので
配列と文字列リテラルとは別の実体を持ち、リテラルではない配列を書き換えることは問題にならない。

初期化子として文字列が出てくるときは初期化の文法としてちょっと特例があるのと
(文字列を含む) 配列は暗黙の型変換で勝手にポインタに変換される特例があって
そういう変則的なルールの積み重ねが分かり難い要因だと思う。

リテラルは書き換えたら駄目なのに型の上では文字列リテラルに const はつかない (C++ では const が付く) ので
ごく単純な場合を除くと書き換えをコンパイラがコンパイル時にエラーとして検出できないこともある。
なるべく (前後の事情によっては出来ないこともあるけど) 変数には const を付けておくのが良い作法だと思う。
const char *cp = "abcdefg";