2009-07-22 8 views
10

各ソースファイルメソッドごとに1つのヘッダーの背後にある目的を理解しようとしています。私が見ているように、ヘッダーは関数宣言を共有するためのもので、typedefとマクロを利用するいくつかのファイルの間にあります。 .cファイルのヘッダーファイルを作成するときには、関数宣言やマクロを表示するたびにヘッダーファイルを参照する必要があり、一般的にすべてが1つのソースファイルに含まれている方が簡単であるという欠点があります。もちろん、ソフトウェア全体)。ソースファイルごとのヘッダー

なぜこの方法をプログラマは使用しますか?

答えて

6

Cのヘッダーファイル(関数を使用する各.cファイルで使用可能)は、定義から1つの場所になければなりません。さらに、ヘッダーファイルにはパブリックインターフェイスだけを置くことができ、.cファイルの内部にある関数や静的変数は記述されていないため、これらは少しモジュール性があります。これは、ファイルシステムを使用してパブリックインターフェイスとプライベートな実装を提供します。

1つの.hファイルから1つの.cファイルへの実行は、ほとんどの場合便利です。そうすることで、あなたは宣言が聖書の中にあることを知っています。hファイル、および対応する.cファイルの定義が含まれています。

+0

私がする必要がある宣言を持っている場合複数のファイルで共有され、論理的に1つの.cファイルに対応していませんか?たとえば、ほとんどのファイルで使用されるいくつかの#defineがあります。それらのすべてを使ってヘッダファイルを作成するほうがいいですか? 1つの.cファイルに関連付けられていない中立なものはありますか? –

+2

はい。アイデアは、各ヘッダーには互いに関連する宣言のグループが含まれているということです。ほとんどの場合、それぞれの.cファイルに対応する.hがありますが、余分な.hファイルを追加することもできます(グローバル定数やenumを定義するなど)。最終的には、ヘッダーを使用してコードを整理する方法を担当しています。 –

+1

@JasonWilliams:または、余分な.cファイル、適切なもの。 – Deduplicator

0

一般に、ソースファイルメソッドのヘッダーは、そのヘッダー内のコンパイル単位の関数のみを宣言することを意味します。

あなたは宣言で汚染されないようにする必要はありません。

個別のコンパイル単位では、コンパイルが高速化され、プライベートシンボルが静的であると宣言された場合の衝突を避けることができます。

1

ソースファイルごとに1つのヘッダーは必要ありません。モジュールごとに1つのヘッダーがあり、パブリックインターフェイスを含み、おそらくそのモジュールのファイル間で共有されるプライベート宣言などを含む追加のヘッダー。

4

あなた自身が言ったように、「ソフトウェア全体」を1つのソースファイルに入れることはできないためです。

プログラムが非常に小さい場合は、はい、すべてを1つの.cファイルに入れるだけです。あなたのプログラムが大きくなるにつれて、関連する関数を異なる.cファイルにまとめて整理することが役に立ちます。さらに、.hファイルでは、であると宣言された宣言を他の.cファイルのものによって使用されるように制限することができます()。 .cファイルに外部からアクセス可能なものが含まれていない場合、ヘッダーは必要ありません。

たとえば、.cが関数foo()とfooHelper()を持っていてfoo()以外の誰もfooHelper()を直接呼び出すことができない場合、foo()とfooHelper()をfoo.cに入れ、 foo()の宣言をfoo.hに入れるだけで、fooHelper()を静的に宣言すると、プログラムの他の部分がfoo()にしかアクセスしないようにし、fooHelper()を知らないと気にする必要はありません。カプセル化のオブジェクト指向でない形式の種類。

最後に、makeエンジンは最後のビルド以降に変更されたファイルのみを再構築できるほどスマートなので、複数の.cファイル(.hファイルを使用して共有するものを共有する)に分割するとビルドのスピードアップに役立ちます。

4

あなたは、他のソースファイルがコンパイルするために必要な最低限のものだけをヘッダファイルに入れます。私はコード・ベースのものがそれらを使用していなくても、ヘッダ・ファイル(すべてのtypedef、すべての#define、すべての構造体など)に非コードをすべて入れている人も見てきました。そのため、ヘッダーファイルは自分自身やモジュールを使用したい人にとっては読みにくくなります。

6

論理、構造化された組織と小さなソースファイルが有効:

  • より速く、より良いプログラミング - より管理し、理解しやすいチャンクにコードを壊すことは、それが簡単に関連するコードを、見つける理解し、編集することができます。
  • コード再利用性 - コードの異なる "モジュール"は、異なるプログラムに統合しやすいソース/ヘッダーファイルのグループに分けることができます。
  • より良い "カプセル化" - ヘッダーを具体的に含む.cファイルのみがその機能を使用することができ、コードのさまざまな部分間の関係を最小限に抑え、モジュール性を助けます。どこからでも物事を使うことを止めるわけではありませんが、なぜ特定のcファイルが特定のヘッダで宣言された関数にアクセスする必要があるのか​​考えるのに役立ちます。
  • エイズのチームワーク - 同じコードファイルを変更しようとしている2人のプログラマが同時に通常、問題を引き起こす(例えば、排他ロック)や余分な作業(例えば、コードマージ)ダウンお互いにその遅いです。
  • 高速コンパイル - ヘッダーが1つの場合は、変更するたびにすべてを再コンパイルする必要があります。多くの小さなヘッダーでは、変更されたヘッダーを#includeする.cファイルのみを再構築する必要があります。
  • 容易に保守&をリファクタリング - すべての上記の理由
  • 特に

、「ソースファイルごとに1つのヘッダー」のためには、それは非常に簡単にあなたが作業しているCファイルに関連する宣言を見つけることができます。複数のヘッダーを1つのファイルにまとめるとすぐに、cファイルとhファイルを関連付けるのが難しくなり、最終的に大きなアプリケーションを構築するのがはるかに難しくなります。小さなアプリケーションで作業しているのであれば、スケーラブルなアプローチを使用する習慣に入るのは良い考えです。それは、クライアントコードと実装が機能の宣言に同意することを保証しながら実装からインターフェイスを分離するためにそれらを可能にするため

3

プログラマは、このメソッドを使用します。 .hファイルは、各関数のプロトタイプについて「真実の単一点」(「自分自身を繰り返さない」を参照)です。

(クライアントコードは、そのエクスポート機能を使用するために#includeの.hファイルのコードですが、.Hのすべての機能を実装していません。)

関連する問題