Wie organisieren Sie Ihre STL-Header?

Question

Ich arbeite an einem großen Projekt, das die STL verwendet und habe eine Frage über Ihre bevorzugte Art, Ihre STL #includes zu organisieren.

• Möchten Sie # jeden Header in der Quelldatei, in der er verwendet wird, einschließen? Wenn zum Beispiel sowohl foo.cpp als auch bar.cppstd::string erfordern, dann werden beide #include <string>.
• Bevorzugen Sie eine einzelne Header-Datei, die alle STL-Header enthält, die Ihr Projekt verwendet (z. B. fügen Sie sie zu dem vorkompilierten Header "stdafx.h" von MS hinzu).

Der Vorteil des ersten Verfahrens ist, dass die CPP-Datei eine eigenständige Einheit ist und kann, ohne sich Sorgen zu machen in einem anderen Projekt verwendet werden, dass Sie eine #include fehlt sind. Die Vorteile der zweiten Methode sind, dass Sie Ihre Compiler vorkompilierte Header-Unterstützung verwenden können und Sie können STL #includes in pragmas, die einige Warnungen deaktivieren (zum Beispiel einige Boost-Header führen Warnungen beim Kompilieren auf Stufe 4) umbrechen.

Welche bevorzugen Sie zu verwenden?

Answer 1

Ich schließe nur die Header-Dateien ein, die wirklich in jeder Quelle benötigt werden, und nicht "alle abfangen" -Kopfzeilen, um Abhängigkeiten (und damit Kompilierzeiten) so niedrig wie möglich zu halten.

Vorkompilierte Header können unabhängig davon funktionieren (d. H. Ich verlasse mich auf vorkompilierte Header, um den Kompilierungsvorgang zu beschleunigen und keine Deklarationen zu erhalten). Selbst wenn etwas über die enthaltenen vorkompilierten Header deklariert wird, schließe ich immer noch den "normalen" Header ein, der vom Include-Guard-Mechanismus übersprungen wird und nichts zu den Kompilierzeiten hinzufügt.

Als vorkompilierte Header sind eine Compiler-spezifische Sache. Das Optimieren/Ändern von vorkompilierten Headern sollte meines Erachtens keine Auswirkung auf das korrekte Funktionieren des Codes haben.

Der Hauptvorteil von Abhängigkeiten so gering wie möglich ist, dass Refactoring leichter wird (oder besser gesagt: machbar)

Großes Buch über all das ist Large Scale C++ Design from Lakos

Answer 2

Total mit dem Vorschlag für John Lakos Buch einverstanden Großen Skalieren Sie C++ Design.

Deklarieren Sie alle Header, die für eine Datei benötigt werden, unabhängig davon, ob .h oder .cpp, in der Datei selbst. Verlassen Sie sich nicht auf Nebenwirkungen von Dateien, die in anderen Header-Dateien enthalten sind.

Eine große Header-Datei, die alle enthält, erhöht die Abhängigkeiten unnötig und macht das Design sehr spröde.

Oh, eine andere Sache nie Deklarationen in einer Header-Datei verwenden. Verwenden Sie sie nur in Ihren Implementierungsdateien, CPP-Dateien.

HTH.

prost,

Rob

Answer 3

Was ich tue, ist, alle STL-Header enthalten, ich werde in dem gesamten Projekt in meinem einzigen precompiled header, in der Regel des Standard StdAfx.h müssen. Ein vorkompilierter Header ist die De-facto-Einrichtung in einem Projekt, einschließlich aller STL-/boost-/Plattform-Header und Bibliotheken von Drittanbietern.

STL & Boost sind ordentlich in Namespaces angeordnet, so dass sie auch keine Verwechslungen oder Überlappungen verursachen.

In Headern verwende ich normalerweise die vollständigen Namen, aber in den Quelldateien tun mit Namespace x, wenn angemessen.

Answer 4

Sie können diese beiden Methoden kombinieren:

beide CPP haben - Dateien enthalten, und es auch StdAfx.h hinzuzufügen. Dies gibt Ihnen immer noch die PCH-Optimierung.

Die .cpp - Datei muss immer noch "stdafx.h" enthalten, daher ist ihre Unabhängigkeit umstritten. Die Abhängigkeit ist jedoch explizit ein Status, und das Entfernen des Include stdafx.h ist einfacher als das Suchen nach allen fehlenden Includes. Außerdem sollten Standard-Header - wie alle Header - sicherstellen, dass sie nicht zweimal enthalten sind.

---

Generell stimme ich Ihren Ansatz für jede Datei „unabhängig“ zu machen, das heißt, wenn die CPP in ein anderes Projekt hinzugefügt wird, oder eine .h enthalten ist, es kümmert sich um seine Abhängigkeiten.

---

Denken Sie daran, dass ein PCH ist ein Kompromiss, sie können sehr groß werden. Zu viel ungenutzter Code im PCH zu haben kann deine Builds verlangsamen. Fast Disks helfen aber sehr, :)

Beachten Sie auch, dass das Aktivieren von vorkompilierten Headern in MSVC zumindest in einigen Versionen tatsächlich die Verarbeitung ändert: Deklarationen vor #include "stdafx.h" werden ignoriert, so dass dies erforderlich ist sei deine erste Nicht-Kommentar-Aussage. Hässliche Fallstricke.