C ++は私が最初に学んだ言語だったので、ソースコードを.hファイルと.cppファイルに分割することは明白に思えましたが、C＃とJavaを学んだことで、今ではひどく不器用に見えます。それらは60年代、おそらく80年代でも有用だったかもしれませんが、セクションフォールディングを備えたIDEやドキュメントジェネレータなどの最新のツールの時代では、時代遅れのように見えます。
とにかく、私の質問は、これら2種類のファイルの存在をプログラマーに透過的にするツールはありますか？たとえば、コーダーにメソッドの定義をヘッダーファイルに一見書かせても、実際には.cppファイルに保存することによって？
（C ++プログラムをヘッダーファイルだけで書き込もうとすることはできますが、これはベストプラクティスとは見なされず、プログラムのビルドがさらに長くなり、2つのクラスが相互に参照することが事実上不可能になります。）
質問、コメント、および他の回答へのコメントで私が見ている議論は、コンポーネントのテキスト表現に焦点を当てているようです。プレーンテキストの観点からは、ヘッダーを完全に削除することは理にかなっています。
一方、ヘッダーとcppファイルの分離には2番目のレベルがあります。これは、インターフェイスを実装から分離し、そうすることで、実装の詳細をインターフェイスから削除します。
これはさまざまな方法で発生します。最も単純なレベルでは、特定の機能を実装する方法は、コンポーネントのユーザーとは無関係です[*]。多くの場合、実装の詳細として使用される.cppファイルにさらに多くのタイプと関数を含めることができます。さらに、特定の機能を直接実装するか、別のライブラリに依存して実装する場合は、実装の詳細であり、ユーザーに漏れないようにする必要があります。
その分離は、ファイルの分離を自動的に管理するツールに実装するのが簡単な場合とそうでない場合があり、ヘッダーのみのライブラリの使用を好む人は実行できません。
定義に移動する必要がないと主張し、コード全体を確認したい場合、コンポーネントのどの部分がユーザーに知られてはならない詳細であるかを柔軟に判断できることがわかります。多くのIDE（そして、vimでも）には、1つのキーストロークの組み合わせがあり、1つから別のIDEに移動します。IDEでは、関数のシグニチャをリファクタリングし、IDEにヘッダーと実装の両方に変更を適用させることができます（場合によっては用途にも）...
ツールにヘッダーと実装の両方の統一されたビューを提供させる場合、作成しているコードのどの部分がインターフェイスまたは実装の一部であるか、および決定をツールに認識させるのはおそらくはるかに困難です。ツールが生成されたプログラムに影響を与える可能性があること。
個別のコンパイルモデルには短所だけでなく長所もあります。ここで行われている議論は、より深い設計上の決定のほんの一部に過ぎないと感じています。
[*]各クラスには独自のヘッダーと.cppファイルが必要だと考える人はかなりいるようですが、私は同意しません。各ヘッダーは、単一のクラス、または複数のクラスと無料の関数の分離である可能性のあるコンポーネントを表します。ファイル内のコードの一部は設計の一部であり、単一のコンポーネントには、1つ以上のパブリック型と、場合によっては1つ以上の内部型が含まれる場合があります。
ソース/ヘッダーへの分割を完全に透過的にするものは何も知りません。
しかし、私はそれをかなり扱いやすくするいくつかのことを知っています。たとえば、Visual Assist Xを使用すると、クラス全体をヘッダーに書き込み、メンバー関数を選択して、それらをソースファイル（つまり、.cppファイル）に移動できます。
それは（決して）完全な治療法ではありませんが、とにかくそれらをはるかに耐えられるものにすることができます/します。
個人的には、ファイルを完全に削除し、代わりにデータベースのようなものを直接使用するのが面白いと思います。つまり、関数のソースコードが1つの列で、オブジェクトコードが別の列である関数のデータベースがあります。それをさらに別の方法で使用する方法に関するコンパイラ情報など。これにより、バージョン管理の統合が非常に簡単になります（基本的には保存されたトランザクションログのみ）。
私は、たとえば、C ++のヘッダーファイルのように、クラスの概要を簡単に説明できる一種の「目次」として機能できるためです。もちろん、これは、ヘッダーを短くし、ほとんどの関数の実装を.cppに入れることを前提としています。
また、メンバー関数の実装をヘッダーから.cppに移動するVisualStudioのプラグインを入手することもできます。さらに、VisualStudioの「gotodefinition」および「gotodeclaration」コマンドにより、ヘッダーは大規模なコードベースをナビゲートするのに非常に役立ちます。
ヘッダーは、C++の現在のコンパイルモデルのかなり基本的なものです。プログラマーを直接header/cppの分割にさらさないと、表現するのが少し難しいことがあると思います。たとえば、特定の状況では、次の間に大きな違いがあります。
// header
class Foo {
Foo() = default;
}
と
// header
class Foo {
Foo();
};
// cpp
Foo::Foo() = default;
それにもかかわらず、コンパイルモデルを改善したり、扱いやすくしたりすることを検討する価値があると思います。
たとえば、プログラマーがコードバブルに定義を記述し、バブルを翻訳単位にグループ化する「コードバブル」スタイルのIDEを想像できます。プログラマーは、定義を「エクスポート済み」としてマークして、他のTUで使用できるようにし、TUごとに、他のユニットからエクスポートされたアイテムを選択してインポートします。また、IDEがプログラムの独自のコードバブル表現を維持している間、IDEをビルドすると、コンパイラへの受け渡し、前方宣言の作成などに必要な実際のcppファイルが生成されます。cppファイルは、単なる中間ビルド製品になります。
ただし、上で示したような微妙な点もありますが、説明したIDEがそれをどのように処理するかはわかりません。