関数をヘッダーに実装し、そのヘッダーを 2 つ以上の異なるソース ファイルにインクルードすると、同じ関数の複数の定義が作成されます。これは、1 つの定義規則に違反しています。
関数をインラインで宣言することでこれを回避することは可能ですが、(リンカが複数の定義をマージする方法を知っていない限り) コードの肥大化につながる可能性があります。
通常、ヘッダーでインライン化された関数を(宣言するだけでなく) 定義します。
また、インライン化されていない関数 (本体が十分に大きい関数など) を宣言し、特定のコンパイル単位で定義 (つまり、実装) します。
次に、リンカはリンク時に適切な関数名 (通常はマングルされた名前) を解決します。そして、複数定義された関数を持ちたくありません。
関数定義を 1 つのコンパイル ユニットのみで提供すると、全体のビルド時間が少し速くなります。
リンク時の最適化(たとえば、コンパイル中とリンク中の両方のオプション-flto) を使用g++すると、事態はさらに複雑になります。
巨大なソフトウェア (一部の実行可能ファイルはほぼ 1 ギガバイトのバイナリーであり、それらをリンクするだけで数分かかります) は、1 人のプログラマーには想像もつかないような制約をもたらすことに注意してください。大規模なフリー ソフトウェア (Libreoffice、Firefox、Qt5 など) をソース コードからコンパイルして、問題を推測してみてください。
ところで、原則として、あるプログラムのすべてのコードを 1 つのソース ファイルに入れることができますが、正当かつ明白な理由により、人々はそうしません。
関数定義をヘッダーに入れると、重要なシステムを使用するときにコンパイル時間が長くなります。小さなプロジェクトではすべてを作成できますinlineが、大規模なシステムでは機能しません（数億行のコードを含む大規模なシステムは言うまでもありません）。
ヘッダー ファイル内の関数宣言は、コードをリンクするために使用できるシンボル参照を提供します。個々のソース ファイルをコンパイルすると、それぞれがオブジェクト コードに生成されます。
あるソースの関数を別のソース ファイルで使用する場合は、そのコードの場所とその呼び出し方法を知る方法が必要です。コンパイラは、まさにこの理由で関数宣言を使用できます。呼び出し方と戻り値はわかっていますが、関数のソースがどこにあるかはまだわかっていません。
すべてのソースがオブジェクト コードにコンパイルされると、リンカはすべてのオブジェクト ファイルを実行可能ファイル (またはライブラリ) にアセンブルし、これらのシンボル参照が解決されます。
すべてのコードが単一の非共有ファイルにある場合、それがどこにあるか (ヘッダーまたはソース ファイル) は実際には関係ありません。
コードをヘッダーとソース ファイルに分割する主な理由は 2 つあります。それらは次のように要約できます。
テクニカル。相互にやり取りする複数のソース ファイルがある場合は、ヘッダーを含める必要があります。ヘッダーですべてを定義すると、コードの複数の定義が含まれることになります。これはコンパイル エラーです。
デザイン。ヘッダー ファイルは、内部実装を公開することなくクライアント ソフトウェアに配布できるソフトウェアのインターフェイスを定義します。