È buona norma fare affidamento sul fatto che le intestazioni vengano incluse in modo transitorio?

Sto ripulendo le inclusioni in un progetto C ++ su cui sto lavorando e continuo a chiedermi se dovrei includere esplicitamente tutte le intestazioni utilizzate direttamente in un determinato file o se dovrei includere solo il minimo indispensabile.

Ecco un esempio Entity.hpp:

#include "RenderObject.hpp"
#include "Texture.hpp"

struct Entity {
    Texture texture;
    RenderObject render();
}

(Supponiamo che una dichiarazione a termine per RenderObjectnon sia un'opzione.)

Ora so che RenderObject.hppinclude Texture.hpp- lo so perché ognuno RenderObjectha un Texturemembro. Tuttavia, includo esplicitamente Texture.hppin Entity.hpp, perché non sono sicuro che sia una buona idea fare affidamento sul fatto che sia incluso in RenderObject.hpp.

Quindi: è una buona pratica o no?

Dovresti sempre includere tutte le intestazioni che definiscono gli oggetti utilizzati in un file .cpp in quel file, indipendentemente da ciò che sai di ciò che è in quei file. Dovresti includere le protezioni in tutti i file di intestazione per assicurarti che includere le intestazioni più volte non sia importante.

Le ragioni:

• Questo rende chiaro agli sviluppatori che leggono la fonte esattamente ciò che richiede il file sorgente in questione. Qui, qualcuno che osserva le prime righe nel file può vedere che hai a che fare con gli Textureoggetti in questo file.
• Ciò evita i problemi in cui le intestazioni refactored causano problemi di compilazione quando non richiedono più particolari intestazioni stesse. Ad esempio, supponi di capire che in RenderObject.hpprealtà non ha bisogno di Texture.hppse stesso.

Un corollario è che non dovresti mai includere un'intestazione in un'altra intestazione a meno che non sia esplicitamente necessario in quel file.

La regola generale è: includi ciò che usi. Se si utilizza direttamente un oggetto, includere direttamente il suo file di intestazione. Se usi un oggetto A che usa B ma non usi B da solo, includi solo Ah

Inoltre, mentre ci occupiamo dell'argomento, dovresti includere altri file di intestazione nel file di intestazione solo se ne hai effettivamente bisogno nell'intestazione. Se ne hai solo bisogno in .cpp, includilo solo lì: questa è la differenza tra una dipendenza pubblica e privata e impedirà agli utenti della tua classe di trascinare le intestazioni di cui non hanno davvero bisogno.

Continuo a chiedermi se dovrei includere esplicitamente tutte le intestazioni utilizzate direttamente in un determinato file

Sì.

Non si sa mai quando quelle altre intestazioni potrebbero cambiare. Ha senso in tutto il mondo includere, in ogni unità di traduzione, le intestazioni di cui hai bisogno.

Abbiamo protezioni di intestazione per garantire che la doppia inclusione non sia dannosa.

Le opinioni differiscono su questo, ma sono del parere che ogni file (sia esso file sorgente c / cpp o file di intestazione h / hpp) debba essere compilato o analizzato da solo.

Pertanto, tutti i file devono includere # tutti i file di intestazione di cui hanno bisogno - non si deve supporre che un file di intestazione sia già stato incluso in precedenza.

È una vera seccatura se devi aggiungere un file di intestazione e scoprire che utilizza un elemento che è definito altrove, senza includerlo direttamente ... quindi devi andare a trovare (e possibilmente finire con quello sbagliato!)

D'altra parte, non importa (come regola generale) se # includi un file che non ti serve ...

Come punto di stile personale, dispongo i file #include in ordine alfabetico, divisi in sistema e applicazione - questo aiuta a rafforzare il messaggio "autonomo e pienamente coerente".

Dipende se tale inclusione transitiva è per necessità (ad es. Classe base) o per un dettaglio di implementazione (membro privato).

Per chiarire, l'inclusione transitiva è necessaria quando la si rimuove può essere effettuata solo dopo aver prima modificato le interfacce dichiarate nell'intestazione intermedia. Poiché questa è già una modifica sostanziale, qualsiasi file .cpp che lo utilizza deve essere controllato comunque.

Esempio: Ah è incluso da Bh, utilizzato da C.cpp. Se Bh usasse Ah per alcuni dettagli di implementazione, C.cpp non dovrebbe supporre che Bh continuerà a farlo. Ma se Bh utilizza Ah per una classe di base, C.cpp può presumere che Bh continuerà a includere le intestazioni rilevanti per le sue classi di base.

Vedete qui il vantaggio reale di NON duplicare le inclusioni di intestazione. Supponiamo che la classe di base utilizzata da Bh non appartenga realmente ad Ah e venga trasformata in Bh stesso. Bh è ora un'intestazione autonoma. Se C.cpp includeva ridondante Ah, ora include un'intestazione non necessaria.

Può esserci un altro caso: hai Ah, Bh e il tuo C.cpp, Bh include Ah

così in C.cpp, puoi scrivere

#include "B.h"
#include "A.h" // < this can be optional as B.h already has all the stuff in A.h

Quindi se non scrivi #include "Ah" qui, cosa può succedere? nel tuo C.cpp, vengono utilizzati sia A che B (ad es. classe). Successivamente hai modificato il tuo codice C.cpp, rimuovi elementi correlati a B, ma lasciando Bh incluso lì.

Se includi sia Ah che Bh e ora a questo punto, gli strumenti che rilevano inclusioni non necessarie potrebbero aiutarti a indicare che l'inclusione di Bh non è più necessaria. Se includi solo Bh come sopra, è difficile per strumenti / umani rilevare l'inclusione non necessaria dopo la modifica del codice.

Sto adottando un approccio leggermente diverso dalle risposte proposte.

Nelle intestazioni, includere sempre solo un minimo indispensabile, proprio ciò che è necessario per far passare la compilation. Utilizzare la dichiarazione anticipata ove possibile.

Nei file di origine, non è così importante quanto includi. Le mie preferenze devono ancora includere il minimo per farlo passare.

Per i piccoli progetti, comprese le intestazioni qua e là, non farà differenza. Ma per progetti medio-grandi, può diventare un problema. Anche se per la compilazione viene utilizzato l'hardware più recente, la differenza può essere evidente. Il motivo è che il compilatore deve ancora aprire l'intestazione inclusa e analizzarla. Quindi, per ottimizzare la build, applica la tecnica sopra (includi minimo indispensabile e usa forward dichlare).

Sebbene un po 'datato, il software di progettazione C ++ su larga scala (di John Lakos) spiega tutto questo in dettaglio.

La buona pratica è quella di non preoccuparsi della tua strategia di intestazione fintanto che si compila.

La sezione header del tuo codice è solo un blocco di righe che nessuno dovrebbe nemmeno guardare fino a quando non ottieni un errore di compilazione facilmente risolvibile. Capisco il desiderio di uno stile "corretto", ma nessuno dei due modi può davvero essere descritto come corretto. Includere un'intestazione per ogni classe è più probabile che causi fastidiosi errori di compilazione basati sull'ordine, ma questi errori di compilazione riflettono anche problemi che potrebbero essere corretti da un'attenta codifica (anche se probabilmente non valgono il tempo per risolvere).

E sì, si dovrà avere quei problemi di ordine basato su una volta che si avvia sempre in friendpaese.

Puoi pensare al problema in due casi.

Caso 1: hai un numero limitato di classi che interagiscono tra loro, diciamo meno di una dozzina. Aggiungete, rimuovete e modificate regolarmente queste intestazioni, in modo tale da influire sulle loro dipendenze. Questo è il caso suggerito dal tuo esempio di codice.

L'insieme delle intestazioni è abbastanza piccolo da non complicare la risoluzione di eventuali problemi. Eventuali problemi difficili vengono risolti riscrivendo una o due intestazioni. Preoccuparsi della tua strategia di intestazione è risolvere i problemi che non esistono.

Caso 2: hai decine di lezioni. Alcune classi rappresentano la spina dorsale del tuo programma e riscrivere le loro intestazioni ti costringerebbe a riscrivere / ricompilare una grande quantità della tua base di codice. Altre classi usano questa spina dorsale per realizzare cose. Ciò rappresenta una tipica impostazione aziendale. Le intestazioni sono distribuite in tutte le directory e non puoi realisticamente ricordare i nomi di tutto.

Soluzione: a questo punto, devi pensare alle tue classi in gruppi logici e raccogliere quei gruppi in intestazioni che ti impediscono di dover #includeripetere ancora e ancora. Non solo questo semplifica la vita, ma è anche un passaggio necessario per sfruttare le intestazioni precompilate .

Ti #includeritrovi in ​​lezioni che non ti servono ma a chi importa ?

In questo caso, il tuo codice sarebbe simile a ...

#include <Graphics.hpp>

struct Entity {
    Texture texture;
    RenderObject render();
}