Ci sono alcuni casi in cui includiamo file cpp, invece di file di intestazione standard (h), ad esempio:Includere cpp invece di intestazione (h)
#include "example.cpp"
invece di
#include "example.h"
Sembra funzionare ma è sicuro o dovrei evitarlo?
E il tempo di compilazione?
È una codifica pigra. Usa i file di intestazione. Sì, possono aumentare il tempo di compilazione, ma significano che puoi facilmente reimplementare blocchi del tuo codice, o meglio ancora, un altro sviluppatore potrebbe in qualsiasi momento. Il file di intestazione funge da modello per ciò che il codice C/C++ sta per fare. È una cattiva idea scartarla o ignorarla.
Sono sempre in uso .h, ma abbiamo un bel dibattito qui ed è per questo che chiedo. – sysop
@sysop - per essere onesti, "La codifica pigra" è un po 'iperbolico. Ci sono casi in cui potrebbe essere effettivamente la cosa giusta da fare, ma nel caso generale direi che è una cattiva forma. – zellio
L'inclusione dei file '.h' invece dei file' .cpp' può velocizzare ** la compilazione molto tempo perché consente di eseguire ricompilazioni parziali. – tom
L'ho usato prima e non ho avuto problemi, ma non posso garantire che questo sia sicuro. A volte questa era l'unica opzione per me, quindi l'ho usata, altrimenti userò il file .h.
C'è sempre un'altra opzione a.k.a. mai dire mai. – LihO
ci sono usi legittimi per #include "impl.cpp":
test per l'accesso alle variabili statiche/etc
modelli ad hoc, come questi, se il meccanismo C++ modello si rivela insufficiente (rara)
#define MACRO (...)
#include "impl.cpp" // uses MACRO
Nota che #include "impl.cpp" può essere pericoloso lo stesso file è incluso in unità di compilazione separate successivamente collegate.
Sono d'accordo con Kerrek SB.
L'ho fatto una volta. Stavo creando una libreria di compressione eccellente e ampiamente utilizzata che doveva essere costruita separatamente per le immagini a 8 bit e per le immagini a 12 bit. Il modo più pulito con cui ho potuto inserirmi nel sistema di build era (semplificando un po ') di avere due file .cpp master, uno che imposta #defines per una build a 8 bit, l'altro per una build a 12 bit. I file master .cpp quindi #includono i file sorgente della libreria di compressione.
Va bene non seguire una regola generale se si capisce bene la regola per conoscerne i motivi e perché potrebbe non essere applicabile nel tuo caso. (Ma quei casi dovrebbero essere rari.)
È sicuro come lo si fa. In genere non dovrebbe essere necessario. La programmazione non riguarda il seguire ciecamente un aereo da carico, ma piuttosto il * capire * cosa stai facendo e prendere decisioni basate sulla comprensione e il ragionamento. –
L'unica ragione valida che abbia mai visto per questo è risparmiare tempo sul collegamento. [Unity Build è spiegato qui] (http://stackoverflow.com/questions/543697/include-all-cpp-files-into-a-single-compilation-unit). –
@sysop: come ho detto: ** capire ** cosa stai facendo e chiedere, prima. Include sono elaborati dal * preprocessore *, molto prima che avvenga qualsiasi compilazione. Comprendi il preprocessore e saprai quando è opportuno includere le cose. –