Gibt es eine Möglichkeit, vorkompilierte Header in VC++ zu verwenden, ohne dass stdafx.h erforderlich ist?

Ich habe eine Menge Legacy-Code, für den ich Unit-Tests schreiben muss. Es verwendet überall vorkompilierte Header, so dass fast alle .cpp-Dateien eine Abhängigkeit von stdafx.h haben, was es schwierig macht, Abhängigkeiten zu durchbrechen, um Tests zu schreiben.

Mein erster Instinkt ist, all diese stdafx.h-Dateien zu entfernen, die größtenteils #include-Anweisungen enthalten, und diese #includes nach Bedarf direkt in die Quelldateien zu platzieren.

Dies würde es erforderlich machen, vorkompilierte Header zu deaktivieren, da sie auf eine Datei wie stdafx.h angewiesen sind, um zu bestimmen, wo die vorkompilierten Header aufhören.

Gibt es eine Möglichkeit, vorkompilierte Header ohne die Abhängigkeiten von stdafx.h zu behalten? Gibt es einen besseren Weg, dieses Problem anzugehen?

Ja, es gibt einen besseren Weg.

Das Problem, IMHO, mit dem ‘Wizard-Stil’ vorkompilierter Header ist, dass sie eine nicht erforderliche Kopplung fördern und die Wiederverwendung von Code schwieriger machen, als es sein sollte. Außerdem ist Code, der mit dem Stil ‘alles in stdafx.h kleben’ geschrieben wurde, anfällig für die Pflege, da Änderungen in einer Header-Datei wahrscheinlich dazu führen, dass die gesamte Codebasis jedes Mal neu kompiliert wird. Dies kann dazu führen, dass einfaches Refactoring ewig dauert, da jede Änderung und jeder Neukompilierungszyklus viel länger dauert, als er sollte.

Ein besserer Weg, wiederum IMHO, ist die Verwendung von #pragma hdrstop und /Yc und /Yu. Auf diese Weise können Sie auf einfache Weise Build-Konfigurationen einrichten, die vorkompilierte Header verwenden, und auch Build-Konfigurationen, die keine vorkompilierten Header verwenden. Die Dateien, die vorkompilierte Header verwenden, haben keine direkte Abhängigkeit vom vorkompilierten Header selbst in der Quelldatei, wodurch sie mit oder ohne den vorkompilierten Header erstellt werden können. Die Projektdatei bestimmt, welche Quelldatei den vorkompilierten Header erstellt und die #pragma hdrstop-Zeile in jeder Quelldatei bestimmt, welche Includes aus dem vorkompilierten Header (sofern verwendet) und welche direkt aus der Quelldatei entnommen werden… Das bedeutet, wenn Bei der Wartung würden Sie die Konfiguration verwenden, die keine vorkompilierten Header verwendet und nur der Code, den Sie nach einer Änderung der Headerdatei neu erstellen müssen, wird neu erstellt. Bei vollständigen Builds können Sie die vorkompilierten Header-Konfigurationen verwenden, um den Kompilierungsprozess zu beschleunigen. Eine weitere gute Sache an der nicht vorkompilierten Header-Build-Option ist, dass sie sicherstellt, dass Ihre cpp-Dateien nur das enthalten, was sie brauchen und alles, was sie brauchen (was schwierig ist, wenn Sie den ‘Assistenten-Stil’ von vorkompilierten Headern verwenden.

Ich habe hier ein wenig darüber geschrieben, wie das funktioniert: http://www.lenholgate.com/blog/2004/07/fi-stlport-precompiled-headers-warning-level-4-and-pragma-hdrstop.html (ignoriere das Zeug über /FI) und ich habe einige Beispielprojekte, die mit der Methode #pragma hdrstop und /Yc /Yu hier bauen: http://www.lenholgate.com/blog/2008/04/practical-testing-16—fixing-a-timeout-bug.html .

Natürlich ist es oft nicht trivial, von der vorkompilierten Header-Nutzung im “Assistenten-Stil” zu einem kontrollierteren Stil zu gelangen …

Wenn Sie normalerweise vorkompilierte Header verwenden, dient “stdafx.h” zwei Zwecken. Es definiert einen Satz stabiler, allgemeiner Include-Dateien. Außerdem dient es in jeder .cpp-Datei als Markierung dafür, wo die vorkompilierten Header enden.

Klingt so, als ob Sie Folgendes tun möchten:

• Lassen Sie den vorkompilierten Header aktiviert.
• Lassen Sie die “stdafx.h” in jeder .cpp-Datei enthalten.
• Leeren Sie die Includes aus “stdafx.h”.
• Finden Sie für jede .cpp-Datei heraus, welche Includes aus der alten “stdafx.h” benötigt wurden. Fügen Sie diese vor dem #include “stdafx.h” in jeder .cpp-Datei hinzu.

Jetzt haben Sie also die minimalen Abhängigkeiten und verwenden immer noch vorkompilierte Header. Der Verlust besteht darin, dass Sie Ihren gemeinsamen Satz von Headern nicht nur einmal vorkompilieren. Dies wäre ein großer Hit für einen vollständigen Umbau. Für den Entwicklungsmodus, in dem Sie nur wenige Dateien gleichzeitig neu kompilieren, wäre dies weniger ein Hit.

Nein, gibt es wahrscheinlich NICHT ein besserer Weg.

Für eine bestimmte einzelne .cpp-Datei können Sie jedoch entscheiden, dass Sie den vorkompilierten Header nicht benötigen. Sie können die Einstellungen für diese eine .cpp-Datei ändern und die Zeile stdafx.h entfernen.

(Eigentlich weiß ich jedoch nicht, wie das vorkompilierte Header-Schema das Schreiben Ihrer Komponententests beeinträchtigt).

Nein. vorkompilierte Header basieren auf einem einzigen Header, der von allen auf diese Weise kompilierten Quellen enthalten ist. Sie können für eine einzelne Quelle (oder alle) angeben, dass keine vorkompilierten Header verwendet werden, aber das ist nicht das, was Sie wollen.

In der Vergangenheit hat der Borland C++-Compiler eine Vorkompilierung ohne einen bestimmten Header durchgeführt. wenn jedoch zwei Quelldateien dieselben Header enthalten, aber unterschiedlich bestellen, sie wurden separat kompiliert, da die Reihenfolge der Header-Dateien in C++ tatsächlich eine Rolle spielen kann…

Das bedeutet also, dass die vorkompilierten Header von Borland nur dann Zeit gespart haben, wenn Sie Quellen sehr starr in der gleichen Reihenfolge einbinden oder eine einzelne Include-Datei (zuerst) von allen anderen Dateien einschließen lassen… – kommt Ihnen bekannt vor?!?!

Ja. Der Name “stdafx.h/stdafx.pch” ist nur Konvention. Sie können jeder .cpp-Datei einen eigenen vorkompilierten Header geben. Dies wäre wahrscheinlich am einfachsten durch ein kleines Skript zu erreichen, um die XML in Ihrem .vcproj zu bearbeiten. Nachteil: Sie haben am Ende einen großen Stapel vorkompilierter Header, die nicht zwischen den TUs geteilt werden.

Möglich, aber klug? Ich kann es nicht genau sagen.

Mein Rat ist – entfernen Sie keine vorkompilierten Header, es sei denn, Sie möchten Ihre Builds schmerzhaft verlangsamen. Grundsätzlich haben Sie hier drei Möglichkeiten:

1. Entfernen Sie vorkompilierte Header (nicht empfohlen)
2. Erstellen Sie eine separate Bibliothek für den Legacy-Code; Auf diese Weise können Sie es separat erstellen.
3. Verwenden Sie mehrere vorkompilierte Header in einem einzigen Projekt. Sie können in Ihrem Projektmappen-Explorer einzelne C++-Dateien auswählen und ihnen mitteilen, welcher vorkompilierte Header verwendet werden soll. Sie müssten auch Ihre OtherStdAfx.h/cpp einrichten, um einen vorkompilierten Header zu generieren.

Vorkompilierte Header basieren auf der Idee, dass alles die gleichen Inhalte enthält. Wenn Sie vorkompilierte Header verwenden möchten, müssen Sie mit den damit verbundenen Abhängigkeiten leben. Es kommt auf einen Kompromiss zwischen den Abhängigkeiten und der Build-Geschwindigkeit an. Wenn Sie in einer angemessenen Zeit bauen können, während die vorkompilierten Header deaktiviert sind, dann tun Sie es auf jeden Fall.

Eine andere zu berücksichtigende Sache ist, dass Sie einen PC pro Bibliothek haben können. So können Sie Ihren Code möglicherweise in kleinere Bibliotheken aufteilen und jede von ihnen mit engeren Abhängigkeiten versehen.