C / C ++ include l'ordine dei file di intestazione

In quale ordine devono essere specificati i file, ovvero quali sono i motivi per includere un'intestazione prima di un'altra?

Ad esempio, i file di sistema, STL e Boost vanno prima o dopo i file di inclusione locali?

Non credo che ci sia un ordine consigliato, purché si compili! La cosa fastidiosa è quando alcune intestazioni richiedono che le altre intestazioni vengano incluse per prime ... Questo è un problema con le intestazioni stesse, non con l'ordine delle inclusioni.

La mia preferenza personale è quella di passare dal locale al globale, ogni sottosezione in ordine alfabetico, ovvero:

1. h file corrispondente a questo file cpp (se applicabile)
2. intestazioni dallo stesso componente,
3. intestazioni di altri componenti,
4. intestazioni di sistema.

La mia logica per 1. è che dovrebbe dimostrare che ogni intestazione (per la quale esiste un cpp) può essere #included senza prerequisiti (terminus technicus: l'intestazione è "autonoma"). E il resto sembra fluire logicamente da lì.

La cosa importante da tenere a mente è che le intestazioni non dovrebbero dipendere da altre intestazioni incluse per prime. Un modo per assicurare ciò è includere le intestazioni prima di qualsiasi altra intestazione.

"Thinking in C ++" in particolare menziona questo, riferendosi al "Design software su larga scala C ++" di Lakos:

Gli errori di utilizzo latenti possono essere evitati assicurando che il file .h di un componente analizzi da solo - senza dichiarazioni o definizioni fornite esternamente ... Includendo il file .h come prima riga del file .c si assicura che nessun pezzo critico delle informazioni intrinseche all'interfaccia fisica del componente mancano dal file .h (o, se esiste, che lo scoprirai non appena provi a compilare il file .c).

Vale a dire, includere nel seguente ordine:

1. L'intestazione prototipo / interfaccia per questa implementazione (ovvero il file .h / .hh che corrisponde a questo file .cpp / .cc).
2. Altre intestazioni dello stesso progetto, se necessario.
3. Intestazioni da altre librerie non standard, non di sistema (ad esempio Qt, Eigen, ecc.).
4. Intestazioni da altre librerie "quasi standard" (ad esempio Boost)
5. Intestazioni C ++ standard (ad esempio, iostream, funzionali, ecc.)
6. Intestazioni C standard (ad esempio, cstdint, dirent.h, ecc.)

Se una delle intestazioni ha un problema con l'inserimento in questo ordine, correggili (se i tuoi) o non utilizzarli. Librerie di boicottaggio che non scrivono intestazioni pulite.

La guida di stile C ++ di Google sostiene quasi il contrario, senza alcuna giustificazione; Personalmente tendo a favorire l'approccio Lakos.

Seguo due semplici regole che evitano la stragrande maggioranza dei problemi:

1. Tutte le intestazioni (e in effetti qualsiasi file di origine) dovrebbero includere ciò di cui hanno bisogno. Non dovrebbero fare affidamento sui propri utenti, comprese le cose.
2. In aggiunta, tutte le intestazioni dovrebbero avere protezioni in modo che non vengano incluse più volte dall'applicazione troppo ambiziosa della regola 1 sopra.

Seguo anche le linee guida di:

1. Includere prima le intestazioni di sistema (stdio.h, ecc.) Con una linea di divisione.
2. Raggruppali logicamente.

In altre parole:

#include <stdio.h>
#include <string.h>

#include "btree.h"
#include "collect_hash.h"
#include "collect_arraylist.h"
#include "globals.h"

Tuttavia, essendo linee guida, è una cosa soggettiva. D'altro canto, le regole vengono applicate rigidamente, fino al punto di fornire file di intestazione "wrapper" con protezioni include e include raggruppate se qualche odioso sviluppatore di terze parti non si abbona alla mia visione :-)

Per aggiungere il mio mattone al muro.

1. Ogni intestazione deve essere autosufficiente, che può essere testata solo se inclusa prima almeno una volta
2. Non si deve modificare erroneamente il significato di un'intestazione di terze parti introducendo simboli (macro, tipi, ecc.)

Quindi di solito vado così:

// myproject/src/example.cpp
#include "myproject/example.h"

#include <algorithm>
#include <set>
#include <vector>

#include <3rdparty/foo.h>
#include <3rdparty/bar.h>

#include "myproject/another.h"
#include "myproject/specific/bla.h"

#include "detail/impl.h"

Ogni gruppo separato da una riga vuota da quella successiva:

• Intestazione corrispondente prima a questo file cpp (controllo di integrità)
• Intestazioni di sistema
• Intestazioni di terze parti, organizzate per ordine di dipendenza
• Intestazioni di progetto
• Progetto intestazioni private

Inoltre, a parte le intestazioni di sistema, ogni file si trova in una cartella con il nome del suo spazio dei nomi, solo perché è più facile rintracciarli in questo modo.

Io raccomando:

1. L'intestazione per il modulo .cc che stai costruendo. (Aiuta a garantire che ogni intestazione del progetto non abbia dipendenze implicite da altre intestazioni del progetto.)
2. File di sistema C.
3. File di sistema C ++.
4. Piattaforma / sistema operativo / altri file di intestazione (ad esempio win32, gtk, openGL).
5. Altri file di intestazione dal tuo progetto.

E, naturalmente, l'ordine alfabetico all'interno di ogni sezione, ove possibile.

Utilizzare sempre dichiarazioni anticipate per evitare messaggi non necessari #includenei file di intestazione.

Sono abbastanza sicuro che questa non sia una pratica consigliata in qualsiasi parte del mondo sano, ma mi piace allineare il sistema in base alla lunghezza del nome del file, ordinato lessicamente nella stessa lunghezza. Così:

#include <set>
#include <vector>
#include <algorithm>
#include <functional>

Penso che sia una buona idea includere le proprie intestazioni prima di altre persone, per evitare la vergogna della dipendenza dall'ordine di inclusione.

Questo non è soggettivo. Assicurati che le intestazioni non facciano affidamento sull'essere #includein un ordine specifico. Puoi essere sicuro che non importa quale ordine includi le intestazioni STL o Boost.

In primo luogo includere l'intestazione corrispondente al .cpp ... in altre parole, source1.cppdovrebbe includere source1.hprima di includere qualsiasi altra cosa. L'unica eccezione che mi viene in mente è quando si utilizza MSVC con intestazioni precompilate, nel qual caso, si è costretti a includere stdafx.hprima di ogni altra cosa.

Ragionamento: l' inclusione del source1.hprecedente prima di qualsiasi altro file garantisce che possa essere autonomo senza dipendenze. Se source1.hassume una dipendenza in una data successiva, il compilatore ti avviserà immediatamente di aggiungere le dichiarazioni forward richieste source1.h. Questo a sua volta garantisce che le intestazioni possano essere incluse in qualsiasi ordine dai loro dipendenti.

Esempio:

source1.h

class Class1 {
    Class2 c2;    // a dependency which has not been forward declared
};

source1.cpp

#include "source1.h"    // now compiler will alert you saying that Class2 is undefined
                    // so you can forward declare Class2 within source1.h
...

Utenti MSVC: consiglio vivamente di utilizzare intestazioni precompilate. Quindi, sposta tutte le #includedirettive per le intestazioni standard (e altre intestazioni che non cambieranno mai) in stdafx.h.

Includi dal più specifico al meno specifico, iniziando con il corrispondente .hpp per il .cpp, se ne esiste uno. In questo modo, verranno rivelate eventuali dipendenze nascoste nei file di intestazione che non sono autosufficienti.

Ciò è complicato dall'uso di intestazioni precompilate. Un modo per aggirare questo è, senza rendere specifico il compilatore del progetto, è utilizzare una delle intestazioni del progetto poiché l'intestazione precompilata include il file.

È una domanda difficile nel mondo C / C ++, con così tanti elementi oltre lo standard.

Penso che l'ordine dei file di intestazione non sia un problema serio finché si compila, come ha detto squelart.

Le mie idee sono: se non vi è alcun conflitto di simboli in tutte quelle intestazioni, qualsiasi ordine è OK e il problema di dipendenza dell'intestazione può essere risolto in seguito aggiungendo #include righe al .h difettoso.

La vera seccatura sorge quando alcune intestazioni cambiano la sua azione (controllando le condizioni #if) in base a quali intestazioni sono sopra.

Ad esempio, in stddef.h in VS2005, c'è:

#ifdef  _WIN64
#define offsetof(s,m)   (size_t)( (ptrdiff_t)&(((s *)0)->m) )
#else
#define offsetof(s,m)   (size_t)&(((s *)0)->m)
#endif

Ora il problema: se ho un'intestazione personalizzata ("custom.h") che deve essere utilizzata con molti compilatori, inclusi alcuni più vecchi che non forniscono offsetofnelle loro intestazioni di sistema, dovrei scrivere nella mia intestazione:

#ifndef offsetof
#define offsetof(s,m)   (size_t)&(((s *)0)->m)
#endif

E assicurati di dire all'utente di #include "custom.h" dopo tutte le intestazioni di sistema, altrimenti la riga offsetofin in stddef.h affermerà un errore di ridefinizione delle macro.

Preghiamo di non incontrare più questi casi nella nostra carriera.