C言語なら俺に聞け 157

2021/06/28(月) 11:22:51.50

!extend:checked:vvvvv:1000:512
(新スレ立ての際上記コマンドを2行書き込んでください)
C言語の話題のみ取り扱います C++の話題はC++スレへ
質問には最低限の情報(ソース/コンパイラ/OS)を付ける
数行で収まらないソースは以下を適当に使ってURLを晒す
https://paiza.io/
https://ideone.com/
http://codepad.org/

C11
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.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言語なら俺に聞け 156
https://mevius.5ch.net/test/read.cgi/tech/1601271690/

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

2021/07/18(日) 17:14:40.88

いいえ

2021/07/18(日) 20:03:28.13

>>34
ありがとうございます！

33 (ｱｳｱｳｷｰ Sa4d-vUbb) · 2021/07/18(日) 20:08:43.08

>>34
すんません
入力欄間違えました。

2021/07/18(日) 21:49:36.58

>>33
真偽値型にキャストした結果の型は _Bool で、 !! を通した型は int という違いはある。

https://wandbox.org/permlink/zlxhRTGr5Sj8IsiH

整数を扱う多くの場合では整数拡張が入ったりして違いが吸収
されてしまうからどちらでもいい場合がほとんどだと思うけど、
あらゆる状況で完全に同じとは言い切れない。

ちなみに C++ では整数に ! を適用した結果は bool なので、
もちろん !! の結果も bool になる。

2021/07/18(日) 21:52:36.39

>>38
違う
一次式を囲む()は
後置式に属する関数呼び出しの()でも
単項式に属するキャスト記法のキャストの()でもない

2021/07/18(日) 22:42:35.27

>>42
_Generic 便利ですね……。C11から追加されたんだ。

2021/07/18(日) 22:44:22.95

>>38
ほとんど関係ないけど，Haskelだと優先度を上げる()記法を
$演算子で代用できるから，
「優先度を上げる()を演算子としてみる」というのはそう不自然ではないかも。

でも（たぶん）C言語だとそういうことはない。

2021/07/19(月) 17:37:03.07

こういう認定試験用にC言語勉強するときって
https://www.sikaku.gr.jp/js/cpjv/
32bit版のコンパイラの方が良いんでしょうか？
64bit版でintとかsize_tとかサイズ変わると困りませんか？

2021/07/19(月) 17:41:05.09

逆にsizeof(size_t)が返す値が処理系定義であることを考え落とす癖がつくと
そこを弱点として狙われるぞ

2021/07/20(火) 15:47:40.82

変わって困ることならむしろ困ってみたほうが勉強になるんじゃね。

2021/07/20(火) 17:03:23.21

> 1級で使用する環境について（公開試験）
コンパイラ Borland C++ Compiler 5.5
JIS X 3010-1993に対応
エディタ TeraPadまたはメモ帳
文字コード：SHIFT-JIS、改行コード：CR+LF

※当コンパイラの操作にはコマンドプロンプトの知識が必要です。
※解答用のソースプログラムは、SHIFT-JISで保存してください。
※指定した保存形式で保存されていない場合は、採点の対象となりません。

・・・なんだかなぁ

2021/07/20(火) 18:27:33.17

せめてC99対応コンパイラにしようよ

2021/07/20(火) 18:37:29.47

JISX 3010 1993で使えない構文や関数を回避して回答する能力を受験者に課すなんてなかなか高度な試験だね

2021/07/20(火) 20:03:33.02

BCCってまだVSの無料版が無かった頃に無料で使えるコンパイラとして粂井氏のHPで紹介されてて使ってたなあ
その時代から何も進化してない資格なんだろうな……

2021/07/21(水) 00:20:28.07

bccとかLSI-C(試食版)とか、Cマガの付録で

2021/07/21(水) 07:39:41.26

BCCは知っててもそれだけじゃ困ります

2021/07/21(水) 09:12:39.48

> JIS X 3010-1993に対応

つーことは
int main(void)
{
printf("");
int x; /* これがダメ */
//このコメントもダメ
for(int y = 0; y < 1; y++) ; //これもダメ
}
今どきのコンパイラはみんなＯＫなのに
うっかり使うと減点されるという陰険な罠だな

2021/07/21(水) 09:45:21.46

検定する側が時代遅れで
しかもこんなレベルじゃ
最早コボちゃん世代を嗤えませんね？

2021/07/21(水) 10:08:36.90

まあそういう時代もあったというのは知識として有るに越したことは無いが、
前提とされるとだいぶんしんどいな。

2021/07/21(水) 11:16:37.45

じじい度検定になっとる

2021/07/21(水) 20:55:54.33

Cの範囲内なのにえらいストレスフルやな
//コメントや for 内の変数宣言が禁じられると辛い

2021/07/21(水) 21:11:33.77

だんだんいじくり回されてワケわからん言語になるんだろうな

2021/07/21(水) 22:43:38.51

>>60
あまり変更するのもどうかと思うけど
昔のままで良しというわけにもいかん部分もあるし、
現実的な妥協点をさぐりながら改定していくしか仕方がないだろ。

2021/07/22(木) 00:04:04.57

今日，O'rellyの『Lex & Yacc』で「自己参照型構造体」という概念を知ったんだけど，
これが動作する理屈とかこういう書き方をする利点がマジでわからなくて苦戦してる。

でもこれを理解できるようになればメモリ確保やポインタ参照の話がわかるようになる……
と期待してがんばる。

2021/07/22(木) 00:13:03.51

基本的なメモリ管理をわからない段階で yacc の本を読んでるのか。
実用を通して理解するのもひとつの道ではあるだろうけど、
最初はもっと単純な事例集みたいなのを見るほうがいいと思う。

**蟻人間** ◆T6xkBnTXz7B0 (ｽﾌｯ Sdfa-rTLR) · 2021/07/22(木) 00:14:52.69

>>62
言わば再帰的定義の産物だよ。
論理的に入れ子の構造にする訳。
ヌルポインタで終わり。

2021/07/22(木) 09:38:36.05

自分が興味あることから掘り下げて行くのはいいと思うよ
とりあえず C言語リスト構造とかでググってみて

2021/07/22(木) 10:14:39.29

struct A { A a; }; ではないからな
struct A { A *p; }; ならただのポインタ

2021/07/22(木) 10:53:20.02

Ruby は、Bison, flex だったか？

2021/07/22(木) 12:38:58.69

>>63
「勉強不足」といわれればそれはその通りなんだけど
寧ろC言語のやっかいな部分にできるだけ触らないですむように
という動機でlexとyaccを学んでるんですよね……。
↑まあこういう考え方が間違ってるかもということに
『Lex & Yacc』を読んでいて気付きはじめていますが……

>>65
こういう↓ことですよね。
https://dev.grapecity.co.jp/support/powernews/column/clang/031/page02.htm
実は『Lex & Yacc』内ではそのコード概念の名前はでてこなくて
コード断片でggったりしてました。

2021/07/22(木) 12:48:57.06

>>66
- A *p;
+ struct A *p;
ここはCスレだぞ

struct A
{
struct A a; //incomplete typeなのでオブジェクトは定義できない
};

2021/07/22(木) 14:18:45.83

「自己参照型」っていうのが
誤訳なんじゃないかって思ってる

実際には「自己型参照型」でしかない
ポインタを代入するときに自分自身(オブジェクト)のポインタを代入する訳じゃないから
自己を参照してる訳じゃないんだ
ここを誤解するから理解が進まない

>>69 君には伝わってるから良いよ

2021/07/22(木) 14:34:42.13

ISO: self-referential structure
JIS: 自己参照する構造体

誤訳かねえ

2021/07/22(木) 14:50:14.55

int arg;
p = (*p)(arg);

戻りが関数(A)のポインタとなる引数int を取る関数(A) の宣言もまた
記述が無理な事案ですかの

2021/07/22(木) 15:29:46.76

自己参照型は、2分木とか？

親は、2つの子のポインターを持っていて、それが再帰的に続くもので、
親子は同じ構造をしているもの

2021/07/22(木) 16:19:06.28

わざわざ「自己参照する構造体」という用語が与えられているのは構造体タグのスコープを
説明する文法解説上の都合じゃないかな。

ノードを直列に接続すればリストになったり複数の接続を持てば木になったりというデータ構造のことと、
他のノードへの接続には C ではポインタを使うのが自然だというふたつの事柄を併せると
結果的に自分自身 (を含む構造体) と同じ型のオブジェクトを指すポインタが現れることもあるというだけのことで、
(データ構造、また、その管理においては) 指している型が同じなのか違うのかで
ことさらに区別して考える意味はあまりないように思う。

2021/07/22(木) 16:44:22.00

C言語の勉強中にリスト構造とかの部分でポインタがよくわからない！って人良く見るけど
実際のところC言語で仕事するときにリストとか二分木ってあんま使わなくね？
構造体の配列は良く見るけど

組み込み系とかだとメモリ少しでも節約するためにリストにしたりするの？

2021/07/22(木) 16:55:22.66

> 組み込み系とかだとメモリ少しでも節約するためにリストにしたりするの？

意味がよくわからんが
組み込みでもリストもmallocも普通に使うぞ
OSがなきゃmalloc使えんとでも思っているのか？

2021/07/22(木) 17:03:27.91

>>76
いや一般的にリソース制約の多い組み込み系だからこそmallocとリスト構造使って
本当に使う分だけメモリ確保するのかなと思ったんだけど
なんか気に触ったのならすみません

2021/07/22(木) 17:12:18.33

> C言語で仕事するときにリストとか二分木ってあんま使わなくね？

気に障るってか、数秒えってなった

2021/07/22(木) 17:27:11.52

>>75
ワイはプロではないし組み込みのこともよう知らんけど
言語処理系を作ったときに当然ながら構文木を組み立てたりはしたし、
宣言した名前を保存するハッシュテーブルはチェイン法を使ったのでリストの一種でもあるわな。
(今なら面倒くさいので C++ で書いてしまう (標準ライブラリのコンテナを使う) だろうけど。)

分野によるとは思うけど、リストや木がそんなにほとんど目にしないというほうが不自然な気がする。

2021/07/22(木) 17:58:20.48

>>77
横からだけどマイコン次第だわな。メモリの動的確保なんて、
そもそも無理ーって処理系もある。コンパイル時にメモリは固定しちゃう。

昨今の32bitのARMマイコンやらESPやら最近触ってるけどmallocも普通にあるし、
サポートライブラリにlistのソース付いてたり（それを使うべきかは悩む）。
更にc++なんかも普通に使えるから、なんか落ち着かんｗ

2021/07/22(木) 21:02:00.87

簡単なテキストエディタ作ってみてください

2021/07/23(金) 00:04:27.67

っsed

2021/07/23(金) 00:26:23.76

あれは簡単なのか？ｗ
コマンド自由に操れる人、果たしているのかな？

2021/07/23(金) 06:51:28.40

作るのが簡単 ≠ 使うのが簡単

2021/07/23(金) 07:52:07.52

えー？　sed禁止とか言われたら立ち直れんぞ

2021/07/23(金) 09:04:13.56

sed awkして(ry

2021/07/23(金) 09:41:53.92

Screen EDitor ですねわかります

2021/07/23(金) 18:17:37.42

よくUnixについての記事や書籍に，
「sedは入力全体を一度に読み込まず一行ごとに処理するから
動作が遅くならず，メモリ容量も気にしなくていい」
みたいなことが書いてあって，それは概ね事実だと思うんだけど，
C言語でsedを実装するときもviを実装するときに比べて
メモリ確保とかが楽なんだろうか。

2021/07/23(金) 19:24:45.90

Ruby では、

IO.readlines は、ファイル内のすべてを読み込むが、
IO#each_line は、1行ずつ読み込む

2021/07/23(金) 19:49:44.19

sedにもホールドスペースがあるから､テキスト全体を読み込んで処理する事も出来る

2021/07/23(金) 23:06:00.86

>>88
そらviよりは楽だろうが、Nコマンドとかで複数行抱える必要はあるし、そもそも数百万桁の行食わされるかもしれんし。
オリジナルsedは確か桁数制限あったよね？

2021/07/24(土) 00:40:19.89

>>91
最新の標準Unixだとsedは最低8192バイトだけ読み込めばいいみたいよ。
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html

2021/07/24(土) 01:03:44.23

POSIX標準は満たすべき最低レベルを規定しているって事ではないかな？
GNU sed の実装はこうみたいだ

For those who want to write portable sed scripts, be aware that some implementations have been known
to limit line lengths (for the pattern and hold spaces) to be no more than 4000 bytes. The POSIX standard
specifies that conforming sed implementations shall support at least 8192 byte line lengths. GNU sed has
no built-in limit on line length; as long as it can malloc() more (virtual) memory, you can feed or construct
lines as long as you like.

62 (ｶﾞｯｸｼ 06eb-qCnf) · 2021/07/26(月) 12:30:48.85

自己参照型構造体（用語法的に正しくないという指摘もあるけど…）がちょっとわかったかも。

はじめは『もう一度基礎からC言語』の第31回「データ構造(10)～構造体をポインタでつなぐ」
https://dev.grapecity.co.jp/support/powernews/column/clang/031/page02.htm
を参考にしてたんだけど，記事集の題名からも察せる通り「初めてC言語を学んでいる」
という状態で読むには向いていなかった。

図書館でそれっぽい本を漁って見つけた，
『C実践プログラミング』の17章「高度なポインタ」にある解説が
初学者としては一番わかりやすかった。
わざわざこのスレで報告する需要はないかもしれないけど，
将来に，おなじような概念の理解で詰まっているひとの
助けになるかもしれないからという言い訳でもって書き込ませてください。

--

C言語でデータ構造を作ろうと思ったら，
基本的にコンパイル時から大きさを決め打ちして用意せざる得ないけれど，
〝無から有を作り出せる〟[*1]malloc関数を用いることで
コンパイル時ではなく実行時に自由に拡大できるという，
記憶領域を食いにくいのに大規模な情報を格納できるデータ構造を作れる。
なぜ構造体を使うのかは自明すぎるためか書籍では明言されていなかった。
あえて言葉にするなら，
C言語において複雑な情報を格納できるデータ構造を作るにあたって
「構造体を定義する」ことはもっとも一般的な慣行であることと，
C言語の演算子に自己参照型構造体の操作に非常に便利な演算子
構造体ポインタ演算子->が用意されているということが決め手なのかな。

*1: ちょっと違う気がするけど，書籍にはそう書いてあった。

2021/07/26(月) 14:20:07.95

https://dev.grapecity.co.jp/support/powernews/column/clang/031/page02.htm
観たけど余談が多過ぎてなかなか本題に入らずイライラするω

あと確かに初心者向けではない
入口にたどり着く前に挫折する文章の書き方だと思う

2021/07/26(月) 14:22:50.46

>『C実践プログラミング』の17章「高度なポインタ」にある解説が

君にとって判り易かったのかも知れないが
君の感想文を読むとあまり良い本ではなさそう

2021/07/26(月) 14:35:32.21

ama zon 4900900648

2冊目か3冊目に読む本
2005年6月21日に日本でレビュー済み
以前、某雑誌の特集で、Ｃがわかればすべてがわかるというのがあり
ましたが、まぁヨイショのし過ぎな文句なのかもしれませんが、依然
として、知っておいたほうがよい言語だと思います。
Ｃでプログラムするような機会は、ほんとここしばらく全くないです
けど、Ｃを勉強していたおかげで今までかなり助かってます。なんと
いってもＣの影響を受けた言語は多いですからね、色々応用がきくも
のなのですよ。
で、肝心のこの本ですが、前訳本でも書きましたが、初心者を脱しよ
うとしている人にとっては最適だと思います。よくありがちな、Ｃの
文法やテクをただ書いているだけの本とは違います。プログラムのス
タイルやプログラムの仕方についての記述が数多くあります。
Ｃのような言語の場合、どのようにコーディングするのか、言い換え
るとWHATだけでなくHOWについて必ず考えなくてはならないと思いま
す。この本は常に、HOWについて意識した記述をしており、そういった
点が、この本を推奨する大きな理由です。
ただ、この本だけで、ポインタとかのキモはさすがに理解できません
でしたので、別の本を読む必要があります。

2021/07/26(月) 14:52:24.77

>>74
>(データ構造、また、その管理においては) 指している型が同じなのか違うのかで
>ことさらに区別して考える意味はあまりないように思う。

それ

>>94
>C言語の演算子に自己参照型構造体の操作に非常に便利な演算子
>構造体ポインタ演算子->が用意されているということが決め手なのかな。

まだ誤解してると思う

2021/07/26(月) 14:57:02.20

不充分。この本だけでは足りない。
2019年4月13日に日本でレビュー済み
敢えてこの本を買う意味が分からない。
20世紀に買ったが、この本だけでは解決できない問題があり、投げた。

よくある fgets & sscanf のコードの部分では、入力バッファのクリアを行う方法が書かれていなかった。
当時はインターネットのコンテンツが今ほど発達しておらず独学ではお手上げ。
他にも何か問題点があった気がするし、今や様々な解説サイト、また「よくある解説サイトの誤りを指摘するサイト」で足りる。

セキュリティ対策についても、wikipediaのサンプルコードやjpcertの「CERT セキュアコーディングスタンダード」など、今では豊富な資料がネットで入手できる。必要なら英文資料だってネットで容易に入手できる（もちろんC99の規格文書も）。

2021/07/26(月) 16:06:22.39

諸々のコンパイラや環境がC11に準拠するようになって久しく、また業務やOSSでもC11で導入された新機能を使うようになってきてる印象があるんだけど（要出典w）、こと並列処理に関してはまだまだC99+POSIXスレッドを使ってた方が良さそうね。
久しぶりに並列処理を書いてみようと思ったんだけど、C11で標準規格として導入されたthread.hに対応してるコンパイラが現時点でも（特にUnix系で）ほとんどないことが意外だった。
今のところthread.hをUnixで使いたかったらmusl Cくらいしか選択肢がないし、
ttps://www.etalabs.net/compare_libcs.html
3年前の電子掲示板の書き込み（要は典拠性が低い）ではあるけど
ttps://www.reddit.com/r/C_Programming/comments/94acpl/c11_vs_pthreads/
ほとんどの人がC11ではなくPOSIXが定めてるスレッド使ってるみたいだし。

せっかく汎OS的に並列処理がかけそうな規格なのに、もったいないというかなんというか。。。

**ハノン** ◆QZaw55cn4c (ﾜｯﾁｮｲ 7be9-8Qmj) · 2021/07/26(月) 20:52:03.28

>>99
＞入力バッファのクリアを行う方法
入力バッファのフラッシュは確か MS のコンパイラだけでしか使えない環境依存だったかと
行末に \n が在る、とかのルールがあれば、それが出るまで読み捨てればいいのですが、そういうルールがなければどうしようもない気が

**ハノン** ◆QZaw55cn4c (ﾜｯﾁｮｲ 7be9-8Qmj) · 2021/07/26(月) 20:54:03.66

>>100
＞せっかく汎OS的に並列処理がかけそうな規格

C11 は調べていませんが、C++ と比べてどうですか？私は C++11 以降でそういうのを書いています‥‥

2021/07/26(月) 21:07:00.92

>>100
C11 のスレッドはオプショナルなのでスレッドを提供しなくても C11 準拠を名乗れる。
C の立場からすれば標準ではあまり高レイヤな機能を要求するのは気が引けるだろうし、
かといっていまどきスレッドに全く触れないでいるというわけにもいかないという妥協なんじゃないかな。

C11 のスレッドの基本的なモデルは POSIX のスレッドとそんなに違いがない (名前が違う程度) ので、
かえって乗り換える強い動機にならないのかも。

62 (ﾜｯﾁｮｲ 2b28-h4Fy) · 2021/07/26(月) 22:30:44.17

>>96
>>98

ご指摘ありがとうございます。
構造体リストについてもう一度勉強しようと思います。
（他の方も書評の引用などありがとうございます）
『C実践プログラミング』のAmazon書評にあった
『Cクイックリファレンス第2版』というのを試しに読んでみたところ，
かなり規格網羅的で丁寧だと感じたので，
当面はこれで勉強してみようと思います。
こちらの書籍には「
struct data {
// some code...
struct data *next
}
」という形のコードの解説そのものはありませんが，
ポインタの解説をCの規格に沿ってしてくれているので
かなり良い教科書として使えそうです。

以後言い訳::
いまのところ，まだC言語の規格が全て頭に入っている状態ですらなく，
ましてや実際のプログラミング作法も分かっていない段階なので，
ある書籍を見たときの（現代における）正確性・信頼性の判断が
できないんですよね……。
『C実践プログラミング』は昔のO'Reillyが出している書籍なので
ある程度信頼できるかな，と思って読み進めていたんですが，
（実際，本質を突いていて分かりやすいと感じる部分も多くありました）
時代的にも正味の内容的にも現代において参考にすべき
良書とはいいがたいのかな……？

2021/07/27(火) 05:25:18.45

ポインターで次へつないでいく、リストみたいな自己参照型。next pointer。
同じ構造体のリスト。
動的関数型のElixir は、片方向リストを使う

a → b → c → d

struct data {
struct data *next
}

これが両方向リストなら、struct data *prev も持たなければならない。
次・前の2方向へ、たどれなければならないから

a ←→ b ←→ c ←→ d

ポインターに、null を代入すれば、次・前は存在しない。
つまり、終端を表す

詳細は、アルゴリズム・データ構造を参照

2021/07/27(火) 10:57:27.91

>>98
いや確かに -> は自己参照する構造体を使うときに好都合だぞ
(*(*p).next).next が p->next->next で済むんだから

2021/07/27(火) 11:05:53.35

双方向で b を削除するのに
b->prev->next = b->next;
b->next->prev = b->prev;
b さよなら
これで済むからありがたい表記ではあるな

2021/07/27(火) 11:39:36.88

>>107
あ、なる
良く出来てんな

2021/07/27(火) 11:42:04.93

忘れずにちゃんと成仏させろよな

2021/07/27(火) 16:12:06.91

>>106
屁理屈

2021/07/27(火) 17:25:02.44

>>110
異論があるなら堂々と言えよ
自分の意見が屁理屈かどうか見せずにそれを言うのは卑怯だぞ

2021/07/27(火) 18:25:54.21

そもそも話がかみあってない
こっちは気付いてるけど
君は気付いていない
ただそれだけ
だから屁理屈

2021/07/27(火) 18:38:55.37

結局、自分は尻尾を見せないんだな
やりあう価値もないゴミだな、唾棄

2021/07/27(火) 18:52:50.94

自己参照型の構造体で固定段数のリンク手繰るのに便利にはなってるけど
自己参照型の構造体があるがゆえに -> ができたんじゃなく
単にポインタの指し先（構造体）のメンバを　(*). じゃ遠回りなので直接指定したいがための存在だと思ってる

2021/07/27(火) 19:55:06.48

>>114
同意だが、.で共用出来なかったんかね？
関数と関数ポインタみたいな感じで、左辺がポインタだったら逆参照してからメンバアクセス。

2021/07/27(火) 23:09:50.37

>>115
Rust ではそうしてるんだから C でも最初からそういう選択も出来たはずではあると思う。
だけど違うことをするのに同じ見た目にするのが良いかどうかというのは微妙なところ。
どちらが良いと一概に言えるもんではないからな。

2021/07/28(水) 00:16:37.31

CはRustの派生だったのか、知らなかった

2021/07/28(水) 00:34:49.35

>>117
派生関係も時系列も前提にしてない。
別の選択をしたものが事実として存在するので可能であるのは疑いないと言ってる。

2021/07/28(水) 00:53:01.29

FortranやCobolにも導入して欲しいのか？

2021/07/28(水) 01:00:09.40

うーん？

ある構文（範疇としては演算子の形態論？）について，
「他の言語での採用例があるからC言語がそういう構文を持っていても不思議じゃなかった」
という話が展開されていたと思うんですけど，
どうして「RustはCの派生」とかFortranやCOBOLの構文の話になったんですかね……？

2021/07/28(水) 01:46:29.97

バカだから

**デフォルトの名無しさん** (JP 0Heb-qCnf) · 2021/07/28(水) 09:52:29.36

C99以降で真偽型をboolのように表記したいときは<stdbool.h>を読み込みますが，
規格票には「型boolはマクロとして定義しろ」とあります。
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2596.pdf#section.7.18

一般に既存の型から新しい表記の型を定義するときはtypedefを使うべきだと
（典拠は失念したのですが）聞いたことがあります。
たしか，コンパイラによる検査があったりより構文的に厳密になったりするから，
というような理由だったはずです。
真偽型boolがtypedefではなくマクロで定義されている理由ってなんでしょうか。

思い当たる理由としては，C++との互換性がありますが，それをC言語の規格で考慮する意味がない
（というか，C++の規格をC側から参照すると循環的になってしまう気がする）
気がします…。
C規格の論理的根拠の真偽型にかんする節も読みましたが，
「typedefではなくマクロを使う理由」は記載されていませんでした。
http://www.open-std.org/JTC1/SC22/WG14/www/docs/C99RationaleV5.10.pdf

2021/07/28(水) 10:26:19.41

マクロだと#undefできるから自分でboolを定義してる古いコードのための移行措置っぽいね
<stdbool.h>をincludeしなければいいと思うけど間接的にincludeされるケースもあるんだろう
_Boolの方は予約語になってる

7.18 (4)
..., a program may undefine and perhaps then redefine the macros bool, true, and false.
プログラムはbool、true、falseマクロをundefineして再定義することができる

7.31.11 (1)
The ability to undefine and perhaps then redefine the macros bool, true, and false is an obsolescent
feature.
⇒　bool、true、falseをundefineして再定義できる特性は廃止されつつある

2021/07/28(水) 12:14:26.76

Win32APIとか使わずに
Cの標準関数でカレントディレクトリではなく
今実行中のexeのpathを得る方法はどれですか？

2021/07/28(水) 12:21:24.51

int main(int argc, char* argv[])
の　argv[0] で実行ファイルへのフルパスがえられるのは環境依存だったかな･･･

2021/07/28(水) 12:22:28.68

mainの第2引数の argv[0] にはコマンドラインから入力した通りのコマンド名が入っているんだっけ
フルパスで入っているんだっけ

2021/07/28(水) 12:24:05.30

被った
たしか Windows はフルパスだったような…
違ってたらごめんなさい

2021/07/28(水) 12:27:22.89

実装に依存

2021/07/28(水) 12:35:40.50

Windows という書き方はよくないかな
シェルの実装によると思います
なので、WSLに持っていくと期待通りに動かなかったりするかもしれません
ここでは Windows限定でよさそうだけど

2021/07/28(水) 13:20:46.92

え？そう？ Windows で C 使う人って今はあまりいないのでは? Linux とかなら分かるけど。

2021/07/28(水) 13:41:10.64

powershellはフルパスだけどｃｍｄは入力のまま
結局はCreateProcessに渡した文字列なのでフルパス前提にしちゃだめよ

OSに依存しない方法で確実なのはないよなぁ
argv[0]が
ファイル名のみ：カレント＋環境変数pathを走査
相対パス：カレントと連結
絶対パス：そのまま
とかやればそこそこいけるだろうけどめんどくさいな

2021/07/28(水) 13:54:41.98

純粋なC標準の範囲では不可能な気がする
カレントディレクトリをとるgetcwd()もPOSIX（unistd.h）だし
C言語の標準ライブラリにはディレクトリ階層の概念自体がなさそう

2021/07/28(水) 13:55:33.60

>>131
powershell と cmd で違うのか…
なんでそうしたんだろ
何れにしても、けぅこう面倒なのね

2021/07/28(水) 14:05:55.87

みなさんありがとうございます
dirname(argv[0]) したら argv[0] が壊れました
ほんとうにがりがとうございました

**蟻人間** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd33-vTy/) · 2021/07/28(水) 14:19:05.25

本当のニガリが10、あったと？

2021/07/28(水) 14:21:25.34

これ解決策じゃなくて愚痴なんだが、main()関数が使えるのはホスト環境で、つまりmain()関数のargv[]引数は「OSによる支援」を前提にできるんだから、実装依存じゃなくて「argv[0]には実行されたファイルのOSにおけるパス名が格納される」みたいな仕様にしてもよかった気がする。
それこそstdint.hみたいに、多種多様な機器への対応を考えなくてもいい関数なんだから、実行環境のファイルシステムやらをある程度は仮定しちゃってもいいわけで。

2021/07/28(水) 16:21:41.95

ファイルシステムもOSもない組み込み機器もあるわけで・・・

2021/07/28(水) 16:21:59.41

>>136
どんな OS でも Unix 風のファイルシステムを採用しているというわけではなくて、
たとえば BTRON が採用しているファイルシステムでは
同名のファイルが存在してよく、ディレクトリのような階層化は存在しない。
全体で唯一に区別できる名前 (フルパスに相当するもの) がない。

OS だってファイルシステムだって多種多様なんで、
起動時に「なんらかの」文字列で情報が与えられるということ以上は
環境依存にならざるを得ないよ。