Comprese le intestazioni delle librerie standard una sola volta tra più intestazioni di programma

Question

Comprese le intestazioni delle librerie standard una sola volta tra più intestazioni di programma

#1 da (6 voti)

3

Sto scrivendo un programma con più intestazioni e file di codice, in questo modo:

message.h
message.cpp
option.h
option.cpp
main.cpp

message.h include option.h come message.cpp richiede la definizione della classe definita al suo interno.

Ci sono parecchi altri file, comunque solo per essere brevi ...
Se voglio chiamare una funzione come memcpy, includo string.h. Includo string.h in message.h - quindi funziona bene in message.cpp, ma se voglio usarlo in option.cpp mi dà un errore.

Quindi vedo due opzioni:

Nell'opzione.h, includo nuovamente message.h. Questo non dovrebbe essere un problema in quanto ho incluso le protezioni in entrambi i file di intestazione, tuttavia ritengo che sia piuttosto complicato.
Includo string.h in option.h. Ora sto includendo string.h in entrambi i miei file di intestazione.

Questo mi dà la dichiarazione per memcpy e quindi posso andare avanti con la mia programmazione. Tuttavia, quando includo 10 diverse intestazioni per molte funzioni diverse, sarà di nuovo disordinato.

Quale è un buon modo per strutturare il mio codice per aggirare questo problema, per mantenere il mio codice il più pulito possibile? Mi è venuto in mente di includere tutti i miei inclusi in un file separato e includere quello in tutti i miei file di intestazione, questo potrebbe essere un problema in futuro, e c'è un modo migliore che posso fare per garantire che il mio codice sia mantenibile?

code-quality c++

posta Shane 11.05.2015 - 07:16

fonte

1 risposta

Leggi altre domande sui tag code-quality c++

Devo fornire il codice sorgente per le dipendenze GPL? Classi e costanti astratte

score 6 · Accepted Answer

È perfettamente corretto includere # include intestazioni aggiuntive nei file .cpp che non sono inclusi nella corrispondente .h. In effetti, dovresti sempre farlo se l'intestazione non è richiesta nel file .h, perché ciò accelera potenzialmente la compilazione di qualsiasi cosa che dipende dal tuo .h ma non dal tuo .cpp. Vedi questo classico Guru della settimana per alcuni suggerimenti su come ridurre i #inclusi non necessari nei file di intestazione (io no pensate che qualcuno di loro sia già scaduto).

In generale, dovresti evitare di fare affidamento su ciò che altri file fanno o non includono il più possibile, poiché ciò rende il tuo codice più modulare (e più portabile ad altre librerie standard). Ciò significa che ogni file dovrebbe esplicitamente e direttamente # include ogni intestazione di cui ha bisogno di sapere (sto assumendo che ogni file di intestazione abbia #include guards o un equivalente come #pragma una volta, dal momento che non avere questi è un problema molto più grande). Se l'autore message.h decide di seguire che GotW I ha collegato e ridotto i loro #inclusi superflui, sarebbe terribilmente frustrante se avesse inconsapevolmente rotto option.h / .cpp nel processo. Al lavoro abbiamo scoperto che parte del nostro codice si compilava sotto GCC ma non in Clang solo perché mancavano alcuni #includes della libreria standard, e quindi inconsapevolmente dipendeva dal fatto che alcune intestazioni GCC si includevano a vicenda.

Quindi la risposta diretta alla tua domanda originale è: dovresti direttamente includere string.h in ogni file che prevedi di usarlo e nessun altro. Supponendo che tu non stia usando memcpy () all'interno di option.h (che sembra improbabile), il che significa che # include appartiene a option.cpp.