Wie kann ich unnötige #include-Dateien in einem großen C++-Projekt erkennen?

Ich arbeite an einem großen C++-Projekt in Visual Studio 2008, und es gibt viele Dateien mit unnötigen #include Richtlinien. Manchmal die #includes sind nur Artefakte und alles lässt sich gut kompilieren, wenn sie entfernt werden, und in anderen Fällen könnten Klassen vorwärts deklariert und das #include nach verschoben werden .cpp Datei. Gibt es gute Tools, um diese beiden Fälle zu erkennen?

Obwohl unnötige Include-Dateien nicht angezeigt werden, verfügt Visual Studio über eine Einstellung /showIncludes (Rechtsklick auf a .cpp Datei, Properties->C/C++->Advanced), die zur Kompilierzeit einen Baum aller enthaltenen Dateien ausgibt. Dies kann beim Identifizieren von Dateien helfen, die nicht eingeschlossen werden müssen.

Sie können sich auch das Pimpl-Idiom ansehen, damit Sie mit weniger Header-Datei-Abhängigkeiten davonkommen, damit Sie den Cruft, den Sie entfernen können, leichter erkennen können.

PC-Fussel funktioniert dafür ganz gut, und es findet auch alle möglichen anderen albernen Probleme für Sie. Es verfügt über Befehlszeilenoptionen, die zum Erstellen externer Tools in Visual Studio verwendet werden können, aber ich habe festgestellt, dass die Visuelle Fussel Addin ist einfacher zu handhaben. Auch die kostenlose Version von Visual Lint hilft. Aber geben Sie PC-Lint eine Chance. Es so zu konfigurieren, dass es Ihnen nicht zu viele Warnungen gibt, braucht ein wenig Zeit, aber Sie werden erstaunt sein, was dabei herauskommt.

Es gibt ein neues Clang-basiertes Tool, schließen Sie ein, was Sie verwendendas darauf abzielt.

!!HAFTUNGSAUSSCHLUSS!! Ich arbeite an einem kommerziellen statischen Analysetool (nicht PC Lint). !!HAFTUNGSAUSSCHLUSS!!

Es gibt mehrere Probleme mit einem einfachen Nicht-Parsing-Ansatz:

1) Überlastsätze:

Es ist möglich, dass eine überladene Funktion Deklarationen enthält, die aus verschiedenen Dateien stammen. Es kann sein, dass das Entfernen einer Header-Datei dazu führt, dass eine andere Überladung ausgewählt wird und kein Kompilierfehler! Das Ergebnis wird eine stille Änderung der Semantik sein, die im Nachhinein nur sehr schwer nachzuvollziehen sein kann.

2) Template-Spezialisierungen:

Wenn Sie partielle oder explizite Spezialisierungen für eine Vorlage haben, möchten Sie, ähnlich wie im Überladungsbeispiel, dass alle sichtbar sind, wenn die Vorlage verwendet wird. Es kann sein, dass sich Spezialisierungen für das primäre Template in unterschiedlichen Header-Dateien befinden. Das Entfernen des Headers mit der Spezialisierung verursacht keinen Kompilierungsfehler, kann aber zu einem undefinierten Verhalten führen, wenn diese Spezialisierung ausgewählt worden wäre. (Siehe: Sichtbarkeit der Template-Spezialisierung der C++-Funktion)

Wie von ‘msalters’ betont, ermöglicht die Durchführung einer vollständigen Analyse des Codes auch eine Analyse der Klassennutzung. Indem überprüft wird, wie eine Klasse über einen bestimmten Dateipfad verwendet wird, ist es möglich, dass die Definition der Klasse (und damit alle ihre Abhängigkeiten) vollständig entfernt oder zumindest auf eine Ebene näher an der Hauptquelle im Include verschoben werden kann Baum.

Ich kenne keine solchen Tools und habe in der Vergangenheit darüber nachgedacht, eines zu schreiben, aber es stellt sich heraus, dass dies ein schwierig zu lösendes Problem ist.

Angenommen, Ihre Quelldatei enthält ah und bh; ah enthält #define USE_FEATURE_X und bh verwendet #ifdef USE_FEATURE_X. Wenn #include "a.h" auskommentiert ist, wird Ihre Datei möglicherweise immer noch kompiliert, tut aber möglicherweise nicht das, was Sie erwarten. Dies erkennen programmatisch ist nicht trivial.

Welches Tool auch immer dies tut, es müsste auch Ihre Build-Umgebung kennen. Wenn ah so aussieht:

#if defined( WINNT )
   #define USE_FEATURE_X
#endif

Dann USE_FEATURE_X ist nur definiert, wenn WINNT definiert ist, also müsste das Tool wissen, welche Anweisungen vom Compiler selbst generiert werden und welche im Kompilierungsbefehl und nicht in einer Header-Datei angegeben sind.

Wie Timmermans kenne ich keine Tools dafür. Aber ich kenne Programmierer, die ein Perl- (oder Python-) Skript geschrieben haben, um zu versuchen, jede Include-Zeile einzeln zu kommentieren und dann jede Datei zu kompilieren.

Es scheint, dass jetzt Eric Raymond hat ein Tool dafür.

Googles cpplint.py hat eine Regel “include what you use” (neben vielen anderen), aber soweit ich das beurteilen kann, keine “include nur was Sie verwenden.” Trotzdem kann es nützlich sein.

Wenn Sie sich allgemein für dieses Thema interessieren, sollten Sie sich Lakos’ Large Scale C++ Software Design ansehen. Es ist ein bisschen veraltet, geht aber auf viele Probleme des “physischen Designs” ein, z. B. das Finden des absoluten Minimums an Headern, die enthalten sein müssen. Ich habe nirgendwo anders wirklich gesehen, dass diese Art von Dingen diskutiert wurde.