ヘッダーの背後にある根拠は何ですか？

Question

私はヘッダーを持っているということをよく理解していません。それはドライ原則に違反しているようです！ヘッダー内のすべての情報は実装に含まれています（可能性があります）。

Answer 1

コンパイルプロセスを簡略化します。独立してユニットをコンパイルする場合は、他のすべてのファイル全体をインポートせずに、リンクされるパーツを記述する必要があります。

また、コードを隠すこともできます。実装を配布することなく他の人が機能を使用できるようにヘッダーを配布することができます。

最後に、インターフェイスと実装の分離を促すことができます。

これらの問題を解決する唯一の方法ではありませんが、30年前はそれが良いものでした。今日の言語ではヘッダーファイルを使用していないかもしれませんが、2009年には作成されていませんでした。

Answer 2

そして、実装を与えずに他の人にあなたのライブラリを使用する宣言を与えたいなら、どうすればよいでしょうか？

もう1つの答えが指摘しているように、ヘッダーの元来の理由は、非常に簡単で限られたツールでプラットフォーム上で解析/コンパイルを簡単にすることでした。 2フロッピーのマシンを持っているので、コンパイラとコードをコンパイラで手に入れることができました。

Answer 3

これは、たとえばcと書かれたときに利用可能だったコンピュータの機能について少し考えるのに役立ちます。主記憶はキロワードで測定されたが、必ずしもそれほど多くはなかった。ディスクは大きかったが、あまり大きかった。熱心なストレージとは、リール・ツー・リール・テープを手でつないで、騒々しいオペレーターが、実際にあなたが離れて、​​ワンパスを狩ることができるようにすることでした。 1 MIPSのマシンは、を叫んででした。これらすべての制限で、シェアです。おそらく、他のユーザーのスコアで。

スペースを小さくしたものまたはコンパイルの時間の複雑さは大きな勝利でした。そしてヘッダーは両方を行います。

Answer 4

Java、Eiffel、C＃などの多くの現代的な言語のアーキテクトが、あなたの意見にはっきりと同意します。これらの言語はモジュールのメタデータを実装から抽出します。しかし、それ自体はヘッダーのコンセプトによって排除されるわけではありません。例えば、コンパイラが.cをコンパイルしているときに、.hファイルを抽出するのは明らかです。他の言語のコンパイラと同様です。典型的な現在のCコンパイラがそれをしないという事実は、言語設計上の問題ではありません - 実装上の問題です。明らかにそのような機能のためにユーザーからの要求はないので、コンパイラベンダはそれを実装するのを煩わしません。

個別の.hファイル（人間が判読可能で編集可能なテキスト形式）を使用することにより、両方の世界で最高の結果が得られます。まだ実装されていないモジュール実装に基づいてクライアントコードを個別にコンパイルすることができますあなたが望むなら、.hファイルを手書きで書くことによって存在します。コンパイラの実装が不条理であると仮定すると、コンパイルの副作用として実装から自動的に.hファイルを取得することができます。

C、C++、& cは、（どうやら彼らはまだ;-)今日罰金やって繁栄し続けると、そして手動でヘッダを書いていないためにあなたのような需要は、最終的には作家が「ヘッダ生成」を提供する必要がありますコンパイラ、成長します両方の世界のベストは理論的なままではありません！ - ）

Answer 5

あなたはJavaでヘッダを持っていけないん - しかし、あなたはインターフェースを持っていると私はすべての深刻なのJavaの第一人者が、あなたはインタフェースと実装などの他のプロジェクト/システムによって使用されるものを定義する推奨しています。ありません

Javaインターフェイス定義には、呼び出しシグネチャ、型定義、および定数が含まれています。

MOST Cヘッダーファイルには、コールシグネチャ、型定義および定数が含まれています。

C/C++ヘッダーファイルはすべての基本的な目的のためにインターフェイス定義なので、GoodSingと見なす必要があります。今、私も（MARCROs、定数などなど）ヘッダファイルに無数の他のものを定義するためにその可能性を知っているが、Cの全素晴らしい世界のほんの一部： -

int function target() { 
    // Default for shoot 
    return FOOT; 
} 

Answer 6

詳細についてthis

を読みます

ヘッダーファイルには、通常、クラス、サブルーチン、変数、およびその他の識別子の前方宣言が含まれます。複数のソースファイルで標準化された識別子を宣言したいプログラマーは、そのような識別子を1つのヘッダーファイルに置くことができます。このコードは、ヘッダーの内容が必要なときはいつでも含めることができます。

C標準ライブラリとC++標準ライブラリは、従来、標準機能をヘッダファイルに宣言していました。

Answer 7

言語プロセッサのバイナリ出力ファイルを調べるという考えは、Cが.hファイルを発明したときには分かりにくいでしょう。そのような何かをしたJOVIALと呼ばれるシステムがあったが、それはエキゾチックであり、軍事プロジェクトに多かれ少なかれ限定されていた。 （私は唯一それについて聞いた陽気プログラムを、見たことがありません。）

Cが出てきたときにモジュール化するための通常のデザインパターンは、「一切のチェック」でした。 .textシンボルは.textと.dataに.dataにしかリンクできないという制約があるかもしれませんが、それはそれでした。つまり、今日のコンパイラは通常、一度に1つのソースファイルを処理し、リンカはそれ以外のエラーチェックを最小限に抑えています。もしあなたが運が良ければ、「私は関数記号です」vs「私はデータシンボル "となる。

だから、実際にコンパイラを持っていることのアイデアは、あなたが呼んでいたものが、やや新しいだった理解しています。

今日でも、あなたが完全に偽のヘッダーを作成した場合、ほとんど誰もあなたをキャッチしませんAOT compilers。 CLR言語やJavaのような賢いことは、実際にはクラスファイル内のものをエンコードします。

したがって、長期的には、おそらくヘッダーファイルはありません。

Answer 8

ヘッダが提供するドキュメントを忘れないでください。通常は、モジュールを使用するために必要な情報があります。ヘッダファイル - 私は私の部分のために、私が使用する必要があり、それを呼び出す方法を...あなたが効果的になり、とにかくこの情報を抽出することをそこにあるものを学ぶためにlooongソースコードをスキャンする必要はありません。もはや当然の近代的なIDEとの問題はない、が、私は本当に使用状況に関する及び事前・事後条件に関するコメントを含んで手作りのヘッダファイルを持っているのが大好きいくつかの古いCコードでの作業。同期中にソース、ヘッダと追加のマニュアルは、まだワームの別の缶で維持

...

Answer 9

あなたはヘッダーとソースファイル内のコードを分割するときは、宣言と定義を分けます。ヘッダファイルを見ると、持っているものを見ることができます。実装の詳細を見るには、ソースファイルに行きます。