Includes in einer main sammeln?
-
Hallo,
In der Vergangenheit habe ich die gesamten Includes, welche meine vielen Code-Dateien benötigen (stl, boost, wxWidgets, meine eigenen Header), in eine main.h geschrieben und diese inkludieret. Leider hat dies die Kompilierzeit und einiges erhöt. Gerade wenn man anfängt, eingeschränkt die Tiefen von boost zu nutzen, mit all dem ganzen Templatespaß (lambda, etc.) kann die Kompilierzeit sehr lange dauern. Da mein Compiler ja leider keine Prekompilierten Headerdateien unterstützt (Microsoft Visual Studio Compiler mit /MP4) habe ich mir gedacht, einfach auf eine solche main.h zu verzichten und dafür wirklich nur die Includes, die ich brauche, per Hand in die cpp reinzubauen.
Lohnt sich der Aufwand? Oder habe ich hier einen Denkfehler und ich sollte lieber an anderer Stelle optimieren?
-
eine zentrale include datei lohnt sich dann, wenn du vorkompilierte header verwendest. siehe compiler doku.
sonst nicht.
-
derblubba schrieb:
...und dafür wirklich nur die Includes, die ich brauche, per Hand in die cpp reinzubauen.
Es ist eigentlich in C++ der übliche Weg immer das zu includieren, was im konkreten Header/Source verwendet wird. Persönlich finde ich das auch ganz gut: Sinn sollte sein, das eine Codeeinheit von anderen Headern (und deren Includes) eher unabhängig sein sollte, und möglichst für sich linkbar ist (geht natürlich nicht immer, aber grundsätzlich wäre es das Optimum).
Precompiled Header lasse ich hierbei mal außen vor, die hebeln dieses Prinzip etwas auseinander [wobei dort nur solche Dateien includiert werden sollten die sich nach Möglichkeit niemals ändern].
cu André
-
derblubba schrieb:
Lohnt sich der Aufwand?
Kurz: Ja. Mit Sammel-Includes stopfst du den Compiler mit Informationen voll die er garnicht braucht, das macht ihn bestenfalls langsamer.
Dazu kommt dass Code auch immer wartbar udn lesbar sein soll. Jetzt stell dir vor, in deinem Code wird irgendeine Helferklasse benutzt, die in einem deiner vielen Header definiert wurde. Jemand der dein Programm warten will muss dafür wissen, was diese Klasse in etwa kann und wie sie benutzt wird, da ists natürlich naheliegend den entsprechenden Header zu öffnen. Zu dumm, dass der einzige Header der eingebunden wird main.h ist und darin wiederum alle Klassendefinitionen eingebunden werden die du jemals für das Projekt erstellt hast. Die Wartung fällt unter den Tisch, weil derjenige keine Lust hat, für eine kleine Änderung in 60 Headern nach der Klasse zu suchen (verständlich oder?)siehe auch hier: http://www.gotw.ca/gotw/007.htm
-
Hi,
ein weiterer Aspekt lässt mich vor solchen "zentralen Headern" zurückschrecken: Die Abhängigkeiten werden künstlich erhöht.
Theoretisch müsste man JEDES Programm neu bauen, testen und ausliefern, sobald sich nur ein einziger Header ändert - mit minimalen Abhängigkeiten kann man sich da Vieles sparen.... und letztlich sind auch nicht alle Header "gut geschrieben"; da kann man sich ganz schnell "Krätze importieren".
Gruß,
Simon2.
-
Natürlich ist ein Master-Header sinnvoll, um die Kompilierzeiten zu verkürzen, aber z.B. der BCC ist auch ohne einen solchen in der Lage, PCHs zu erstellen und zu verwenden, wenngleich der Aufwand für den Compiler dann spürbar größer wird (ein Master-Header ist noch schneller). Wie das bei MSVC und GCC aussieht, weiß ich nicht.
Darüber hinaus gibt es in C++Builder 2009 einen Wizard, der einen solchen Master-Header zusammenstellt, vorcompiliert und implizit in allen Quelldateien einfügt, diejenigen ausgenommen, in denen bei einem Test-Build Fehler auftreten. Spätestens da ist es müßig, so etwas von Hand anzulegen.
-
audacia schrieb:
Natürlich ist ein Master-Header sinnvoll, um die Kompilierzeiten zu verkürzen,...
Das mag für verwendete Bibliotheken gelten, aber nicht generell. In der Regel sollte man nur das Includieren was an der entsprechenden Stelle notwendig ist. Alles was sich weder ändert und an vielen Stellen Verwendung findet, kann (je nach Philosophie und Verwendung von PCHs) in einen solchen globalen Header.
Dies sollte aber nicht allgemeingültig für alles ausgesprochen werden (Ich persönlich mag PCHs trotz ihren Vorteilen nicht, da ich gerne sehe was ich in einer Codeeinheit benötige - Wenn ein Compiler daraus dann intern einen PCH generieren kann - okay, keine Einwände).
cu André