per esempio, ho A.h, che ha una classe A con alcuni metodi vuoti:
class A : public B{
public:
A(){
}
virtual void b(){
}
~A(){
}
//other methods
};
dovrei spostare tutta la definizione dei metodi vuoti in A.cpp:
#include A.h
A::A(){
}
void A::b(){
}
A::~A(){
}
//other methods
? e qual è il modo più consigliato?
O è perfettamente legale e dovrebbe generare lo stesso codice con i compilatori moderni. (Per un compilatore semplice, potrebbe non provare il codice inline che non si trova nell'intestazione e generare una chiamata inutile a una funzione vuota, ma dubito che qualsiasi compilatore reale sarebbe così semplice). C'è un piccolo potenziale tempo risparmi al momento della compilazione se non hai avuto bisogno di .cpp - un file in meno per il compilatore da aprire / leggere - ma questo è davvero banale. Quindi la domanda è davvero più sensata da usare per gli umani coinvolti.
La prima regola che uso è "When in Rome". Se un altro codice nel sistema su cui stai lavorando lo fa in un modo o nell'altro, segui questo esempio. Mescolare gli stili porta a confusione, quindi tienilo coerente.
Se non ci sono precedenti, puoi fare quello che vuoi. Personalmente userò l'approccio in linea quando definisco una classe base che non fa nulla che tu voglia sovrascrivere da altri. Questo rende chiaro che non stai facendo nulla nella base senza che nessuno debba scavare nell'implementazione.
Se è un override probabilmente lo inserirò nel file .cpp. C'è una buona ragione per farlo? Probabilmente no. Ma mi sembra giusto.
P.S. Dovresti rendere virtuale anche questo distruttore!
Se stai fornendo una libreria di sola intestazione , non hai altra scelta e non la prenderò in considerazione ulteriormente.
Se i metodi sono necessariamente vuoti, la definizione nell'intestazione di solito è soddisfacente (anche se può essere una confusione visiva, che può essere evitata definendo al di fuori della dichiarazione della classe).
Se l'implementazione potrebbe cambiare a causa di requisiti futuri, tieni presente che il codice compilato rispetto alla versione precedente richiederà la ricompilazione per ottenere la nuova implementazione. È improbabile che si verifichi un problema all'interno di un singolo albero di build, ma se stai fornendo una libreria condivisa, ti consigliamo di evitarlo, poiché può introdurre problemi difficili da diagnosticare.
Se i metodi sono compito di costruttore, distruttore o copia / spostamento, dichiarare esplicitamente = default potrebbe essere ciò che vuoi invece. C'è una sostanziale differenza tra la definizione di qualsiasi metodo vuoto e la dichiarazione come predefinita.
Un utente della classe vorrebbe che ci fosse un'implementazione vuota? L'implementazione vuota è corretta? In tal caso, chi guarda il file .h per capire l'interfaccia non dovrebbe preoccuparsi di quale particolare implementazione hai. Dove metti i metodi con implementazioni molto brevi? O implementazioni di medie dimensioni? O lunghe implementazioni? Dovrebbero stare tutti insieme nello stesso posto.
Se l'implementazione è vuota perché non l'hai ancora implementata, potrebbe essere opportuno inserirla nel file di intestazione come promemoria.
Come regola generale dovresti mantenere la dichiarazione nei file header e nelle definizioni nei file cpp. Una definizione vuota è effettivamente una definizione, quindi dovrebbe essere nel file cpp.
Mettere le definizioni nei file di intestazione potrebbe anche portare a problemi come la ridefinizione dei simboli quindi consiglio assolutamente di non farlo
Tecnicamente, è lo stesso. La direttiva #include A.h significa fondamentalmente che il preprocessore semplicemente copierà il contenuto del file .h al posto della direttiva #include e andrà avanti.
Personalmente, mi piace mantenere le dichiarazioni in .h e le definizioni nei file .cpp. È una bella convenzione e rende le cose più prevedibili.