複数の関数の定義を含むヘッダー ファイルを作成している場合、同じヘッダー内に関数宣言も含めることをお勧めするのはなぜですか? 定義自体で十分な場合、宣言を含めるのは冗長に思えます。
さらに、宣言の目的を理解しようとしています。関数が宣言と同じファイルで定義されていない場合、別のファイルで宣言を単独で使用して関数を使用することはできないようです。
それがどのように使用されたかの良い例として役立つ特定のケースはありますか?
複数の関数の定義を含むヘッダー ファイルを作成している場合、同じヘッダー内に関数宣言も含めることをお勧めするのはなぜですか? 定義自体で十分な場合、宣言を含めるのは冗長に思えます。
さらに、宣言の目的を理解しようとしています。関数が宣言と同じファイルで定義されていない場合、別のファイルで宣言を単独で使用して関数を使用することはできないようです。
それがどのように使用されたかの良い例として役立つ特定のケースはありますか?
通常、宣言はヘッダー ファイルに配置し、定義は実装ファイルに配置します。これにはいくつかの理由があります。
1) 読みやすさが向上し、コードを読む可能性のある他の人に「関数リスト」を提供します。
2) たまたまライブラリを製品化した場合、完全なソース コードをリリースしなくても、ヘッダー ファイルとライブラリのバイナリだけを出荷できます。
3) プラットフォームに依存する実装を作成する必要がある場合は、同じヘッダー用にコンパイルされる別の実装を持つことができます。
リストは続く可能性がありますが、それが行われる基本的な理由は、他の誰もがそれが行われることを期待しているからです。
この規則にはいくつかの例外があります (インライン、静的、およびテンプレート)。どのような場合でも、ヘッダー ファイルをスコープ ガードして、ヘッダー ファイルが複数回取り込まれないようにする必要があります。
他の回答で言及されていない重要な側面の 1 つはコンパイル速度です。関数定義がコンパイラに表示されるたびに、そのコードが指定された翻訳単位内で不要で冗長であっても、コンパイラはコードを生成する必要があります。別のコンパイル単位が実際にコンパイルされた関数を提供することを知ることはできません。
ほとんどのヘッダー ファイルは 2 回から 10 回コンパイルされます。関数定義をヘッダーに配置すると、その関数のコンパイルが同じ要因で遅くなります。
プロジェクトが小さいため、これは重要ではないかもしれませんが、変更、コンパイル、テストのサイクルに大きな影響を与える可能性があるため、大規模なプロジェクトでは重要になります。これは、同等の C++ プログラムをコンパイルするよりも C プログラムをコンパイルする方がはるかに時間がかからない大きな理由の 1 つです。
ヘッダファイルを読む人にとっては、実装を読まなくても、すべての宣言を 1 か所で見る方が簡単だと思うかもしれません。
そうは言っても、同じヘッダーと私が見たテンプレートクラス(boost::scoped_ptrなど)で宣言関数を転送する必要があるかどうかはわかりません。人々は宣言関数を転送することを気にしません