Rilevamento di #inclusi in C / C ++?

Trovo spesso che la sezione delle intestazioni di un file diventi sempre più grande ma non diventa mai più piccola. Nel corso della vita di un file sorgente le classi potrebbero essere state spostate e modificate ed è molto probabile che ce ne siano alcune #includesche non devono più essere presenti. Lasciandoli lì solo prolunga il tempo di compilazione e aggiunge inutili dipendenze di compilazione. Cercare di capire quali sono ancora necessari può essere piuttosto noioso.

Esiste un tipo di strumento in grado di rilevare le direttive #include superflue e suggerire quali posso rimuovere in modo sicuro?
La lanugine lo fa forse?

Non è automatico, ma doxygen produrrà diagrammi di dipendenza per i #includedfile. Dovrai esaminarli visivamente, ma possono essere molto utili per ottenere un'immagine di ciò che sta usando cosa.

Il cppclean di Google (link a: download , documentazione ) può trovare diverse categorie di problemi C ++ e ora può trovare #inclusi superflui.

C'è anche uno strumento basato su Clang, include quello che usi , che può farlo. include-what-you-use può anche suggerire dichiarazioni in avanti (quindi non è necessario #includere così tanto) e facoltativamente ripulire i tuoi #include per te.

Le versioni attuali di Eclipse CDT hanno anche questa funzionalità integrata: andando nel menu Sorgente e facendo clic su Organizza Includi in ordine alfabetico le tue # include, aggiungi eventuali intestazioni che Eclipse pensa di utilizzare senza includerle direttamente e commenta le intestazioni che non ha non credo che tu abbia bisogno. Questa funzionalità non è affidabile al 100%, tuttavia.

Guarda anche include-what-you-use , che risolve un problema simile.

Il problema con il rilevamento di inclusioni superflue è che non può essere solo un controllo di dipendenza del tipo. Un'inclusione superflua è un file che non fornisce alcun valore alla compilazione e non modifica un altro elemento da cui dipendono altri file. Esistono molti modi in cui un file di intestazione può modificare una compilazione, ad esempio definendo una costante, ridefinendo e / o eliminando una macro utilizzata, aggiungendo uno spazio dei nomi che altera la ricerca di un nome in qualche modo lungo la riga. Per rilevare elementi come lo spazio dei nomi è necessario molto più di un preprocessore, in realtà è quasi necessario un compilatore completo.

Lint è più un controllo di stile e sicuramente non avrà questa piena capacità.

Penso che troverai l'unico modo per rilevare un'inclusione superflua è rimuovere, compilare ed eseguire le suite.

Pensavo che PCLint avrebbe fatto questo, ma sono passati alcuni anni da quando l'ho visto. Potresti verificarlo.

Ho guardato questo blog e l'autore ha parlato un po 'della configurazione di PCLint per trovare inclusioni non utilizzate. Potrebbe meritare un'occhiata.

Il browser di refactoring di CScout è in grado di rilevare direttive di inclusione superflue nel codice C (purtroppo non C ++). Puoi trovare una descrizione di come funziona in questo articolo di giornale.

È possibile scrivere uno script rapido che cancella una singola direttiva #include, compila i progetti e registra il nome in #include e il file da cui è stato rimosso nel caso in cui non si siano verificati errori di compilazione.

Lascialo funzionare durante la notte e il giorno successivo avrai un elenco corretto al 100% di file include che puoi rimuovere.

A volte la forza bruta funziona :-)

modifica: e a volte no :-). Ecco alcune informazioni dai commenti:

1. A volte è possibile rimuovere due file di intestazione separatamente, ma non entrambi insieme. Una soluzione è rimuovere i file di intestazione durante l'esecuzione e non ripristinarli. Questo troverà un elenco di file che puoi rimuovere in modo sicuro, anche se potrebbe esserci una soluzione con più file da rimuovere che questo algoritmo non troverà. (è una ricerca avida nello spazio dei file di inclusione da rimuovere. Troverà solo un massimo locale)
2. Potrebbero esserci sottili cambiamenti nel comportamento se alcune macro sono state ridefinite in modo diverso a seconda di alcuni #ifdefs. Penso che si tratti di casi molto rari e i test unitari che fanno parte della build dovrebbero rilevare questi cambiamenti.

Siamo spiacenti di (ri) pubblicare qui, le persone spesso non espandono i commenti.

Controlla il mio commento a crashmstr, FlexeLint / PC-Lint farà questo per te. Messaggio informativo 766. La sezione 11.8.1 del mio manuale (versione 8.0) ne discute.

Inoltre, e questo è importante, continua a ripetere fino a quando il messaggio non scompare . In altre parole, dopo aver rimosso le intestazioni non utilizzate, rieseguire lint, un numero maggiore di file di intestazione potrebbe essere diventato "non necessario" dopo aver rimosso alcune intestazioni non necessarie. (Potrebbe sembrare sciocco, leggerlo lentamente e analizzarlo, ha senso.)

Non ho mai trovato uno strumento completo che realizza ciò che stai chiedendo. La cosa più vicina che ho usato è IncludeManager , che rappresenta graficamente l'albero di inclusione dell'intestazione in modo da poter individuare visivamente cose come le intestazioni incluse in un solo file e le inclusioni circolari dell'intestazione.

Ho provato ad usare Flexelint (la versione unix di PC-Lint) e ho ottenuto risultati piuttosto contrastanti. Questo è probabilmente perché sto lavorando su una base di codice molto grande e intricata. Consiglio di esaminare attentamente ogni file segnalato come inutilizzato.

La preoccupazione principale sono i falsi positivi. Molteplici inclusioni della stessa intestazione vengono riportate come intestazione non necessaria. Ciò è negativo poiché Flexelint non ti dice su quale riga è inclusa l'intestazione o dove è stata inclusa in precedenza.

Uno dei modi in cui gli strumenti automatici possono sbagliare:

In A.hpp:

class A { 
  // ...
};

In B.hpp:

#include "A.hpp

class B {
    public:
        A foo;
};

In C.cpp:

#include "C.hpp"  

#include "B.hpp"  // <-- Unneeded, but lint reports it as needed
#include "A.hpp"  // <-- Needed, but lint reports it as unneeded

Se segui ciecamente i messaggi di Flexelint, confonderai le tue dipendenze #include. Ci sono più casi patologici, ma fondamentalmente dovrai ispezionare tu stesso le intestazioni per ottenere i migliori risultati.

Consiglio vivamente questo articolo su Physical Structure e C ++ dal blog Games dall'interno. Raccomandano un approccio globale per ripulire il disordine #include:

Linee guida

Ecco una serie distillata di linee guida dal libro di Lakos che minimizzano il numero di dipendenze fisiche tra i file. Li uso da anni e sono sempre stato molto contento dei risultati.

1. Ogni file cpp include prima il proprio file di intestazione. [Omissis]
2. Un file di intestazione deve includere tutti i file di intestazione necessari per analizzarlo. [Omissis]
3. Un file di intestazione deve avere il numero minimo di file di intestazione necessario per analizzarlo. [Omissis]

Se stai usando Eclipse CDT puoi provare http://includator.com che è gratuito per i beta tester (al momento in cui scrivo) e rimuove automaticamente #includi superflui o aggiunge quelli mancanti. Per quegli utenti che hanno FlexeLint o PC-Lint e usano Elicpse CDT, http://linticator.com potrebbe essere un'opzione (anche gratuita per il beta test). Mentre utilizza l'analisi di Lint, fornisce soluzioni rapide per rimuovere automaticamente le istruzioni #include superflue.

Questo articolo spiega una tecnica di rimozione di #include usando l'analisi di Doxygen. Questo è solo uno script perl, quindi è abbastanza facile da usare.

Forse un po 'in ritardo, ma una volta ho trovato uno script perl WebKit che ha fatto esattamente quello che volevi. Avrà bisogno di qualche adattamento credo (non sono esperto in perl), ma dovrebbe fare il trucco:

http://trac.webkit.org/browser/branches/old/safari-3-2-branch/WebKitTools/Scripts/find-extra-includes

(questo è un vecchio ramo perché trunk non ha più il file)

Esiste uno strumento gratuito Include File Dependencies Watcher che può essere integrato in Visual Studio. Mostra i # # superflui in rosso.

Esistono due tipi di file #include superflui:

1. Un file di intestazione in realtà non è necessario per il modulo (.c, .cpp)
2. Il modulo richiede un file di intestazione, ma viene incluso più di una volta, direttamente o indirettamente.

Esistono 2 modi nella mia esperienza che funziona bene per rilevarlo:

• gcc -H o cl.exe / showincludes (risolvi il problema 2)

  Nel mondo reale, puoi esportare CFLAGS = -H prima di make, se tutti i Makefile non hanno la precedenza sulle opzioni CFLAGS. O come ho usato, puoi creare un wrapper cc / g ++ per aggiungere forzatamente le opzioni -H a ogni invocazione di $ (CC) e $ (CXX). e anteporre la directory del wrapper alla variabile $ PATH, quindi make farà invece uso del comando wrapper. Ovviamente il tuo wrapper dovrebbe invocare il vero compilatore gcc. Questi trucchi devono cambiare se il tuo Makefile usa direttamente gcc. invece di $ (CC) o $ (CXX) o secondo regole implicite.

  Puoi anche compilare un singolo file modificando la riga di comando. Ma se vuoi pulire le intestazioni per l'intero progetto. È possibile acquisire tutto l'output:

  pulire

  fare 2> & 1 | tee result.txt

• PC-Lint / FlexeLint (risolvi il problema sia 1 che 2)

  assicurati di aggiungere le opzioni + e766, questo avviso riguarda: file di intestazione inutilizzati.

  pclint / flint -vf ...

  Ciò causerà l'output di pclint inclusi i file di intestazione, i file di intestazione nidificati verranno rientrati in modo appropriato.

Per concludere questa discussione: il preprocessore c ++ è in fase di completamento. È una proprietà semantica, se un'inclusione è superflua. Quindi, dal teorema di Rice risulta che è indecidibile se una inclusione sia superflua o meno. NON può esserci un programma, che (sempre correttamente) rileva se una inclusione è superflua.

Ecco un modo semplice forza bruta per identificare le intestazioni superflue include . Non è perfetto ma elimina le inclusioni "ovvie" non necessarie. Sbarazzarsi di questi fa molto per ripulire il codice.

È possibile accedere agli script direttamente su GitHub.

PC Lint di Gimpel Software può riferire quando un file include è stato incluso più di una volta in un'unità di compilazione , ma non riesce a trovare i file include che non sono necessari nel modo che stai cercando.

Modifica: può. Vedi la risposta di itsmatt

CLion , l'IDE C / C ++ di JetBrains, rileva gli insiemi ridondanti pronti all'uso . Questi sono disattivati ​​nell'editor, ma ci sono anche funzioni per ottimizzare le inclusioni nel file corrente o nell'intero progetto .

Ho scoperto che paghi per questa funzionalità però; CLion impiega un po 'di tempo per scansionare e analizzare il progetto al primo caricamento.