プライベートメンバーをヘッダーに配置する必要があるのはなぜですか？

プライベート変数は、クラスのユーザーに複雑さと実装の詳細を隠す方法です。これはかなり良い機能です。しかし、なぜc ++ではクラスのヘッダーに入れる必要があるのか​​理解できません。これには2つの厄介な欠点があります。

• ユーザーからのヘッダーを乱雑にします
• 内部が変更されるたびに、すべてのクライアントライブラリの再コンパイルを強制します

この要件の背後に概念的な理由はありますか？コンパイラの作業を簡単にするだけですか？

これは、C ++コンパイラがインスタンス化時に適切な量のメモリを割り当てるために、クラスの実際のサイズを知っている必要があるためです。また、サイズにはすべてのメンバーが含まれ、プライベートメンバーも含まれます。

これを回避する方法の1つは、ハーブサッターの週の達人シリーズ＃24および＃28で説明されているPimplイディオムを使用することです。

更新

確かに、（より一般的に、ヘッダ/ソースファイルを区別し、この#includeS）はC ++での大きな障害である、日中C.戻るから継承されたC ++ Cを作成したところ、この、大規模なソフトウェア開発とは経験が、まだありませんでした本当の問題を引き起こし始めます。それから学んだ教訓は新しい言語の設計者に注意されましたが、C ++は後方互換性の要件に縛られているため、言語のこのような根本的な問題に対処することは非常に困難です。

クラスの定義は、クラスのオブジェクトを使用した場所にかかわらず、コンパイラがメモリ内で同一のレイアウトを生成するのに十分である必要があります。たとえば、次のようなものが与えられた場合：

class X { 
    int a;
public:
    int b;
};

コンパイラーは通常a、オフセット0およびbオフセットにあり4ます。コンパイラがこれを単なるものと見なした場合：

class X { 
public:
    int b;
};

これはb、オフセット4ではなくオフセット0にあるべきだと「考え」ます。その定義を使用するコードがに割り当てられている場合b、最初の定義を使用するコードaは変更されます。

クラスのプライベートな部分に変更を加えることによる影響を最小限に抑える通常の方法は、通常pimplイディオムと呼ばれます（これについてはGoogleが多くの情報を提供できると確信しています）。

いくつかの理由が考えられます。他のほとんどのクラスはプライベートメンバーにアクセスできませんが、フレンドクラスは引き続きアクセスできます。したがって、少なくともこの場合、ヘッダーで必要になる可能性があるため、フレンドクラスはそれらが存在することを確認できます。

依存ファイルの再コンパイルは、インクルード構造に依存する場合があります。別のヘッダーではなく.cppファイルに.hファイルを含めると、場合によっては再コンパイルの長いチェーンを防ぐことができます。