【自キ】.cと.hの違いがわからん

調べ始めたら説明が下手な人たちばかりで混乱する。


この違いをわかるには、
コンパイルが何をしているかを理解しないと理解できない、
というところまではあってるかな。
リンカとか言ってるし。リンクが何をすることかは理解していない。

.hが絵に描いた餅で、.cが餅の本体だけど、
それは習慣的なものでどっちでも良い、
というところまで読んで、調べるのをやめた。

そもそも#includeで、
cはファイルを結合することさえ知らなかったのだ。
薄々感じてたが、そこに全コピペするとは。
となると順番が大事になるはずで、
何順に並べるんだ？

コンパイルが何をどう動かしてるのか、
という概要には辿り着くことができず、
呪文解読の気力が奪われた。


全くの初心者ではないが、
しばらく実地経験があるので、
中級者ほどの知識ではない、
こうした人たち向けの解説があると大変助かるが、
その検索の仕方がわからんよね。

殆どの解説が、粒度が細かすぎるか荒すぎる。
ちょうど良い粒度の解説を検索する方法はないものか…

こういう時リアルの人に聞ければ、
質問の粒度で相手は答えの粒度を変えてくれる。
何が分からんか分からんから、
検索オプションだけでは難しいのう…

本を読む方が早いのか、
適当にコピペして動かしてみる方が早いのか、
なやましい。

Comments

.cが1冊の書籍とすると、.hは参考文献リストだと私は思っています。
参考文献リストと違って、書くのは書籍の先頭ですけどね。

参考文献リストに載るような内容というと、
この単語の定義とか、このデータが算出されるまでの過程といったものですが、
これってなんだか変数とか関数の働きと似てないでしょうか。

単語の定義や過程の論拠はその書籍の論旨では無く、
あくまで正しさの保証ですので、
1冊の本にズラズラ全部書いておくのは紙の無駄ですよね。
ただし最低限、出典先は書いておかないと
そのデータほんとに信頼できるのか？と
読者(Cの場合はコンパイラ)から指摘が入るわけです。
ですので、この変数や関数はこの本には書いてないけど、
どこかにあるので指摘しないでねと
コンパイラに通知するのがhファイルの中身の仕事です。

たまに.cを#includeしているようなkeymap.cとかありますけど、
あれは参考文献リストの部分に
他の書籍として纏めるべき内容を
全部ベタ書きしているようなものです。
インクルードしてる内容が書籍に満たない
紙束のような(それだけではコンパイル出来ない)内容だった場合は
#includeの使い方を拡大解釈しているのではと、私は思います(出典なし)。

Posted by trp3l at 2022年01月27日 13:49

内容がごちゃつきそうだったので、コメント分けさせていただきます。

本文でリンカがとか、結合がとか書かれていましたので、その事について。

そもそもCのコンパイラが2段階に分けて
ファイル群の結合行っているのが
混乱の元になっているのだと思われます。

先程のコメントで色々書いたhファイルのincludeは、
一つのcファイルをコンパイルする段階の話です。


コンパイラは全ての.cを個別にコンパイルして
.oファイルというものを作成したあと、
最後に.oファイルの結合を行い(リンク)、
実行ファイル(.hexなど)を完成させます。
つまり、コンパイルとリンクは別の仕事です。



QMKをcliで実行している時にコンソールを眺めていると
コンパイル……
コンパイル……
リンク
と、コンパイルが並んだあと
最後に一回だけリンクが実行されているのが分かるかと思います。

なぜそのような過程を取るかと言うのは、
上記の段階を逆にして.oファイルの部分を省略してみるとわかります。
つまり、膨大なcファイル群を結合(リンク)したあと
一挙にコンパイルして実行ファイルを作るということです。
こうすると、修正箇所は1ファイルだけなのに、
全ファイルをコンパイルし直すハメになります。

機械にとって馴染みやすい文章(.o)を
くっつけるだけの作業なら簡単ですが、
翻訳(コンパイル)はそれなりに時間がかかるので、
コンパイルした文章を最後にくっつける
という過程をCのコンパイラは行っているようです。
細かい所は間違っていると思いますが、大筋は多分こんな感じかと……。
私も詳しく調べたわけではなく、
使っていく中でこんな感じなのかなと理解していった程度なので
本職の人から指摘頂けると正直ありがたいです。

コンパイル後のリンク前ファイル群はqmk/.build/の中に各キーマップ毎に保管されてます。

Posted by trp3l at 2022年01月27日 14:31

>trp3lさん

ありがとうございます。
大体自分の理解であってた。

で、そもそも、
「c言語は複数のファイルを統合して作るものである」を、
誰も説明してない（フォルダみれば複数ファイルがあるからわかるとはいえ）んですよ。
なんでそうするのか、そのメリットとデメリットはなにか、
を誰も説明してくれなくて。

ユニット化することのメリットデメリットは想像できたとして、
「その相互ファイル参照図と、全体の構成」は、
どこにあるのか、ないのか、自動で作れるのか、作れないのか、
が調べようがないんですよね。
おそらく.hファイルだけの全貌骨格図があると思うんだけど、
そんなのみんな作ってないっぽくて、
んんん？と思うわけです。
これがみずほ銀行で「誰もシステムの全貌を把握してない」ってこと？
なんて思ってしまうわけですが、
その辺の解説の探し方がわからんので、
まあいいや進めよ、となりました。

今、コルネv3を今組み立てているんですが、
v3なのにファームウェアはrev1を使うことになっていて、
rev3はないの？と思って複雑な沢山のファイルを見ながら、
これ全体が見えてる人っているのかなあと思った次第。
開発者環境が整ってればわかるのかしら。
Windowsの単なるファイルシステムではなにもわからん。

で、とりあえずrev1を書き込んだらキー自体は認識したので、
前には進めるものの、
釈然としないんですよね。

Posted by おおおかとしひこ at 2022年01月27日 14:35

>trp3lさん

リンクがどの段階でのリンクなのかが、
専門用語を使わずに説明できる人がいないのが問題かなあと思いました。

コンパイルって二段階あるんですよ、
翻訳と結合。
個別翻訳をコンパイルといって、
翻訳済みのやつを組み合わせるのを結合というんです。
結合は速くて翻訳が遅いので、
こうした仕組みにしてるんです。
（一括コンパイルだけでなく、指定した部分の翻訳や、
指定した結合の仕方も可能ですよ）
と、日本語で説明できる人がいないことが、
ややこしさを増していると思いましたね。

で、こうした概要の後に、
実際の.oやら.hexやら、実体の格納場所やら、
どれどどれが要素として存在して、
みたいな具体的な話をしてくれれば完全に理解できるのになあ。


なんとなくの構造は、
キーマップを変更したときや、
コンフィグを変更したときの、
コンパイルの挙動の差でわかっていましたが、
これくらい簡単になぜ理系の人は説明できないのだまったく、
と、広告をやってる身から憤慨。

技術用語だからある程度は覚悟してたけど、
みんな説明が下手だなあ…

Posted by おおおかとしひこ at 2022年01月27日 14:45

どの.cファイルを使うかという、設計図、骨格の部分は.mkファイルの仕事ですね。
厄介なことにこれも複数に分れているらしく、
rules.mkの他にも関連しそうなフォルダを探してみると色々見つかります。
コルネは特にそこらへんの網目が複雑ですよね。

mkファイルの中身に何が書いてあるのかに関しては勉強不足で私にはほとんどわかりません……。
これがif文にあたる表現か……？といった感じで、なんとなくで辿ってます。

文のわかりやすさに関しては耳が痛い限りです。
なるほど、専門用語とそれの例えを同時に出すのではなく、
まずは例えで全部説明し、専門用語との紐づけはあとから行うという
ほうが分かりやすいですね。
解説記事とかを書く際に気をつけようと思います。

Posted by trp3l at 2022年01月27日 15:28

>trp3lさん

ファイルシステムだとアルファベット順に並んでるのがまず最初の罠ですよね。
大事な順から並べて欲しいなあといつも思います。
rules.mkはいつも最後の方なので、
それが大事かどうかがなかなか分からないもんですねえ。

仕事でフォルダをつくるときは、
見て欲しい順に00_ 01_ なんてヘッダをつけて、
自動で並べられても大丈夫なようにしてますね。
MacOS9の頃は、並び順はファイル名でなくて、
こっちで決められたのは便利だったなあ。

複雑なシステムは、
「今俺は真ん中を見ていて、間違ったよそを見てないぞ」
と確信できる何かが必要だと思いますね。

Posted by おおおかとしひこ at 2022年01月27日 15:39