たとえば、いくつかの空のメソッドを持つクラスAを持つA.hがあります。
class A : public B{
public:
A(){
}
virtual void b(){
}
~A(){
}
//other methods
};
空のメソッド定義をすべてA.cppに移動する必要があります。
#include A.h
A::A(){
}
void A::b(){
}
A::~A(){
}
//other methods
?そしてどちらがよりお勧めの方法ですか?
どちらも完全に合法であり、最新のコンパイラで同じコードを生成する必要があります。 (単純なコンパイラーの場合、ヘッダーにないコードをインライン化して空の関数への無用な呼び出しを生成しようとはしないかもしれませんが、実際のコンパイラーが単純なものであるかどうかは疑問です。)小さな潜在的な時間があります。 .cppがまったく必要ない場合のコンパイル時の節約-コンパイラーが開いたり読み取ったりするファイルが1つ少なくなります-しかし、それは本当に簡単です。したがって、問題は実際に、関係する人間に使用する方が理にかなっていることです。
私が使用する最初のルールは「ローマにいるとき」です。作業中のシステムの他のコードが何らかの方法でそれを実行する場合は、そのリードに従ってください。スタイルを混在させると混乱が生じるため、一貫性を保つようにしてください。
前例がない場合は、好きなことをすることができます。あなたが他の人によってオーバーライドされるつもりのない基本クラスを定義するとき、私は個人的にインラインアプローチを使用します。これにより、実装を掘り下げることを誰かに要求することなく、ベースで何も実行していないことが明らかになります。
上書きの場合は、おそらく.cppファイルに入れます。これを行う大きな理由はありますか?おそらく違います。しかし、それは私には正しいと感じています。
追伸そのデストラクタも仮想化する必要があります!
ヘッダーのみのライブラリを提供している場合、選択の余地はありません。それ以上は考慮しません。
メソッドが必要に応じて空の場合、ヘッダーでの定義は通常は問題ありません(ただし、視覚的に混乱する可能性があります。クラスの外部で定義することで回避できます)宣言)。
将来の要件のために実装が変更される可能性がある場合、以前のバージョンに対してコンパイルされたコード再コンパイルが必要になりますに注意してください新しい実装を取得します。単一のビルドツリー内で問題になることはほとんどありませんが、共有ライブラリを提供している場合は、診断が難しい問題が発生する可能性があるため、それを回避する必要があります。
メソッドがコンストラクタ、デストラクタ、またはコピー/移動割り当ての場合、明示的に= default
代わりにしたいかもしれません。空のメソッドを定義することとデフォルトとして宣言することの間には実質的な違いがあります。
クラスのユーザーは、空の実装があることを気にしますか?空の実装は正しいですか?その場合、.hファイルを調べてインターフェイスを理解する人は、特定の実装を気にする必要はありません。非常に短い実装のメソッドをどこに置きますか?または中規模の実装ですか?または長い実装?それらはすべて同じ場所に一緒になければなりません。
まだ実装していないために実装が空の場合は、リマインダーとしてヘッダーファイルに挿入するのが適切な場合があります。
原則として、ヘッダーファイルでの宣言とcppファイルでの定義を維持する必要があります。空の定義は確かに定義なので、cppファイルに入れる必要があります。
ヘッダーファイルに定義を配置すると、シンボルの再定義などの問題が発生する可能性があるため、絶対に行わないことをお勧めします