Enforcing inclusione manuale di un file di intestazione specifico (banned.h)

Dopo un lungo dibattito, abbiamo trovato un metodo che ci piace, ma ha comportato altre modifiche sostanziali al progetto. Abbiamo attivato le intestazioni precompilate . All'interno dell'intestazione precompilata, prima includiamo tutte le intestazioni di sistema (e altre intestazioni di libreria di terze parti) che non sono conformi a banned.h, e quindi includiamo banned.h.

Questo ha molte proprietà che ci interessano:

1. Non rallenta la build, anche se sono incluse intestazioni raramente utilizzate. In realtà, una build completa richiede meno della metà del tempo che aveva prima, perché le intestazioni precompilate sono un'ottimizzazione.
2. Non puoi inavvertitamente lasciare fuori banned.h, perché il compilatore impone l'inclusione dell'intestazione precompilata . Le intestazioni precompilate sono un'impostazione dell'intero progetto in Visual Studio e i singoli file devono essere esplicitamente disattivati se non desiderano utilizzarli. Quindi banned.h viene applicato in modo pulito ovunque.
3. Possiamo forzare-includere l'intestazione precompilata per evitare di cambiare ogni file sorgente, oppure possiamo aggiungerlo all'inizio di ogni file sorgente. Questo ha fornito un bel percorso di migrazione. Tutte le nostre regole di eccezione per determinati file sorgente sono andate via.
4. Tutti i compilatori di cui ci occupiamo (GNU C ++, clang, Visual C ++) supportano le intestazioni precompilate e il supporto è abbastanza simile da non richiedere #ifdefs o hack simili.

C'è uno svantaggio che ci ha catturato: se nel progetto sono stati combinati file sorgente C ++ e C, sarà necessario disporre di file banned.h separati per loro. Non è possibile utilizzare lo stesso file PCH per entrambe le lingue. Poiché tutta la nostra sorgente C proveniva da una libreria di terze parti, abbiamo deciso di creare un file lib separato per esso e collegarlo a valle, che ha risolto il problema. Ora non richiediamo impostazioni di progetto personalizzate per i singoli file sorgente, il progetto viene compilato rapidamente e stiamo implementando completamente banned.h.

Ok, non lo farei mai in un milione di anni, ma potresti fare qualcosa del genere:

Forza l'inclusione automatica di questo:

// forcebanned.h
#define for "You must include banned.h"

Quindi aggiungi questo:

// mybanned.h
#undef for
#include banned.h

Ma non farlo. Meglio è rendere l'inclusione di banned.h uno standard di codifica e affidarsi alle revisioni del codice per catturarlo.

Se sei davvero insistente nell'applicare tecnicamente questo, potresti avere una fase di compilazione personalizzata che grep'd file per "banned.h" prima della compilazione, fallendo la compilazione se la linea non viene trovata. (Oppure usa uno strumento di analisi statica che tagga le funzioni deprecate.) Facendo così parte della build mantieni il tuo codice più semplice e più portabile.

Potresti, invece di usare banned.h, scrivere un programma di analisi Clang che analizzi il tuo codice sorgente. Puoi usarlo per far rispettare le regole di codifica o le linee guida che ti piacciono, non solo il divieto di un set specifico di funzioni C, e puoi anche interrogare la posizione di origine di ogni dato codice e implementare regole specifiche per la posizione.