Ich habe ein Framework, das von mehreren Projekten verwendet wird (es enthält mehrere Beispiele, um zu zeigen, wie das Framework funktioniert). Das Framework hat Komponenten wie den Kern, Grafiken, Physik, GUI usw. Jeder ist eine separate Bibliothek. Es gibt verschiedene Konfigurationen.
Eine Hauptlösungsdatei kompiliert das vollständige Projekt mit allen möglichen Konfigurationen, so dass die Projekte die Bibliotheken verwenden können. Da das Framework nur selten rekompiliert wird, insbesondere wenn jemand (einschließlich mir) an einem Projekt arbeitet, das das Framework verwendet, macht es Sinn, die vielen Header vorab zu kompilieren.
Zunächst hatte ich für jedes Projekt / jede Probe einen eigenen vorkompilierten Header, der für das gesamte Projekt verwendet wurde. Jedes Mal, wenn ich das selbe pch neu aufbauen müsste (zum Beispiel Debug), entschied ich, dass ein geteilter PCH die redundante PCH-Kompilierung reduzieren würde. So weit, ist es gut. Ich habe ein Projekt, das den PCH zusammen mit den Bibliotheken kompiliert. Alle folgenden Projekte / Proben verwenden jetzt den gleichen PCH. Das hat wunderbar funktioniert.
Das einzige Problem ist, dass ich eine Zunahme der Dateigröße gesehen habe. Dies ist kein Hindernis, als ob ein Projekt, das das Framework verwendet, veröffentlicht werden soll, es kann sich von dem geteilten PCH trennen und sein eigenes machen. Ich habe dies aus Gründen der schnellen Entwicklung gemacht (ich habe tatsächlich ein Werkzeug erstellt, das die VS-Projektdateien und Quelldateien für ein neues Projekt / eine neue Probe erstellt und ein Upgrade eines früheren Projekts, das einen älteren verwendet, ermöglicht Version des Rahmens).
Wie auch immer (ich nehme an, dass), ist die Zunahme der Dateigröße darauf zurückzuführen, dass die unabhängige VS-Projektdatei, die den freigegebenen PCH erstellt, alle Header aus allen Bibliotheken enthält. Meine Frage ist, ob ich die bedingte Kompilierung (#ifndef) verwenden kann, um die Größe der endgültigen ausführbaren Datei zu reduzieren? Oder vielleicht teilen Sie mehrere PCH-Dateien irgendwie (soweit ich weiß, das ist nicht möglich, aber ich vielleicht falsch) Wenn ich keinen Sinn mache, bitte sag es (in freundlichen Worten :)), da mein Wissen über PCH-Dateien sehr begrenzt ist .
Danke!
Hinweis: Um es noch einmal zu wiederholen und zu verdeutlichen, habe ich bisher eine Lösungsdatei, die alle Bibliotheken einschließlich des freigegebenen PCH kompiliert. Jetzt, wenn ich alle Samples und Projekte neu kompiliere, kompilieren sie in ein paar Sekunden oder mehr. Zuvor erstellte jedes Projekt eine PCH-Datei. Außerdem wollte ich zunächst eine PCH für jede Bibliothek, aber dann fand ich heraus, dass eine Quelldatei nicht mehrere PCH-Dateien verwenden kann, daher war diese Option nicht möglich. Eine andere Möglichkeit besteht darin, alle möglichen Kombinationen von PCH-Dateien zu kompilieren, aber das ist zu zeitaufwendig und umständlich und fehleranfällig.
Es scheint, dass das Größenproblem von der Verwendung von Headern kommt, die Sie eigentlich nicht brauchen, aber dass es immer noch Sinn macht, diese Header beim Entwickeln wegen des schnelleren Umdrehens zu verwenden.
Bei mit #ifndefs: Die Vorkompilierung ist grob. Sie verlieren die Fähigkeit, die Vorkompilierungsarbeit an dem Punkt zu teilen, an dem es Unterschiede gibt. Wenn Sie #ifndefs verwenden, um verschiedene Varianten von dem, was Sie einschließen, zu erstellen, z. wenn du
hast %Vor%Dann muss der vorkompilierte Header vor dem Punkt enden, an dem FOO in zwei Dateien, die diesen vorkompilierten Header verwenden, anders definiert ist. Also wird #ifndef das Problem nicht lösen. Das Endergebnis ist, dass FOO identisch sein muss, oder Sie sind zurück zu separaten PCH-Dateien für die verschiedenen Projekte. Weder löst noch Dinge.
gemeinsame Nutzung mehrerer .pch-Dateien: Eine grundlegende Einschränkung von .pch-Dateien besteht darin, dass jede .obj nur eine .pj-Datei verwenden kann. Natürlich können .pch-Dateien beliebige Kombinationen von Headern haben. Du könntest ein .pch für Core + Grafik, ein .pch für Core + Physik, Core + Ai usw. haben. Das würde nur gut funktionieren, wenn keine der Source-Dateien mehr als Core + One-Module bei einem "sprechen" müsste Zeit. Das klingt für mich nicht realistisch. Solch ein Schema und Varianten darauf klingen wie viele Umstrukturierungsarbeiten für keinen wirklichen Gewinn. Sie wollen keine Zillionen von Kombinationen erstellen und sie alle im Auge behalten. Es ist möglich, aber es wird dir nicht Zeit sparen.
Meiner Meinung nach machst du genau das Richtige, indem du die Größe der ausführbaren Dateien für den schnellen Turnaround während der Entwicklung / Fehlersuche opfierst und dann eine langsamere, aber schlankere Art und Weise für die eigentliche Veröffentlichung aufbaust.
In der Vergangenheit habe ich festgestellt, dass Sie ziemlich schnell mit abnehmenden Renditen konfrontiert werden, wenn Sie mehr in die vorkompilierten Header eingeben. Wenn Sie also mehr hinzufügen möchten, um es in einer größeren Anzahl von Projekten nützlicher zu machen wird einen Punkt treffen, der sich verlangsamt. Bei unseren Projekten benötigen die PCH-Dateien länger als die meisten Quelldateien, aber nur wenige Sekunden. Ich würde vorschlagen, die PCH-Dateien für jedes Projekt spezifisch zu machen. Sie haben recht damit, dass eine Quelldatei sich nur auf eine einzelne PCH-Datei beziehen kann, aber eine Möglichkeit, dies zu umgehen, ist die Verwendung der Option "erzwinge" (auf der Registerkarte Erweitert, denke ich), um sicherzustellen, dass alle Dateien den PCH enthalten Datei für dieses Projekt.
Tags und Links c++ visual-studio-2008 precompiled-headers