#pragma hdrstop in Header-Dateien
-
Hallo,
da in meinem Projekt die Compilezeit langsam unerträglich zugenommen hat, möchte ich Precompiled-Headers optimal nutzen:
Die Direktive #pragma hdrstop bewirkt, dass die davor stehenden Includes als vorcompilierter Header verwendet werden dürfen.
Borland selbst verwendet diese nur bei vorgegebenen Bibliotheken wie z.B. vcl.h .Ausserdem werden diese immer nur in cpp-Dateien und nicht in Header-Dateien verwendet.
Kann man dieses Pragma in .h-Dateien verwenden, da ich die meisten Includes in den .h-Dateien mache?
Gibt es sonst noch was zu beachten?Danke
-
Borland C++Builder-Hilfe schrieb:
Präprozessor-Direktiven werden gewöhnlich am Anfang des Quellprogramms plaziert, sind aber an jeder beliebigen Stelle des Programms zulässig. Der Präprozessor von Borland C++ erkennt Präprozessor-Direktiven (auch Steuerzeilen genannt) und zerlegt sie in die darin enthaltenen Symbole.
demzufolge kann man pragma auch im header verwenden.
inkludieren musst du im header nur, wenn der header das erfordert, ansonsten gehören die inkludes in die cpp.
beispiel:
hier muss #include <IniFiles.hpp> nicht im header stehen, da es dort nicht für die definition von TIniFile benötigt wird.
// im Header void BlahFasel(AnsiString FileName); // im cpp #include <IniFiles.hpp> void BlahFasel(AnsiString FileName) { TIniFile *Ini = new TIniFile(FileName); // ... delete Ini; }das #pragma hdrstop hab ich bisher auch nur in den cpp benötigt. das macht allerdings nur sinn, wenn du in all deinen projektdateien die gleichen header inkludierst.
folgendes bringt dir überhaupt nichts, da die vorkompilierten header nicht mehr übereinstimmen, d.h. in unit1 sind 3 vorkompilierte header und in unit2 nur 2.
// Unit1.cpp #include <vcl.h> #include "meine_unit1.h" #include "meine_unit2.h" #pragma hdrstop // Unit2.cpp #include <vcl.h> #include "meine_unit1.h" #pragma hdrstopum das compilieren zu beschleunigen, kannst du dir auch einen globalen header erstellen, der alle deine projektdateien (units) inkludiert. diesen einen header inkludierst du dann in jedem formular. dann sind alle header gleich und beimn compilieren, wird nur einmal der globale header erstellt und als vorkompilierter header verwendet. nachteil: du hast dann natürlich in jeder unit alle header drin, was unschön werden kann, wenn du einzelne units in anderen projekten verwenden willst und dort nur einen teil der funktionen benötigst.
#ifndef __MY_GLOBAL_HEADER_H #define __MY_GLOBAL_HEADER_H //--------------------------------------------------------------------- #include <vcl.h> #include <clipbrd.hpp> #include <filectrl.hpp> //--------------------------------------------------------------------- #include "meine_unit1.h" #include "meine_unit2.h" //--------------------------------------------------------------------- #endif
-
Zunächst mal vielen Dank für die ausführliche Antwort.
In meinem Fall sind mir speziell die STL-Header ein Klotz am Bein.
Auch verwende ich viele Klassen und diese kommunizieren miteinander, daher muss ich z.B. bei typisierten Parametern diese bereits in der H-Datei inkludieren.
Da ich die STL sehr viel einsetze und auch selbst mit Templates arbeite, kommt mir gerade der Gedanke, dass diese gar nicht vorcompiliert werden können, weil erst beim Aufruf für den Compiler klar ist, was zu tun ist.
Kann das sein?
-
Hallo
ja, das ist der Fall. Das liegt aber weniger daran, das es die STL ist, sondern daran das die STL (wie der Name ja schon sagt) aus Templates besteht. Und diese werden immer zur Compilezeit ausgewertet und mit den angegeben Typen spezialisiert, wenn sie angewendet werden. Aus diesem Grund müßen bei Templates auch die komplette Implementation für das Compilen vorhanden sein, nicht nur die Definition.
Dieser Effekt besteht aber auch bei selbstgeschriebenen Templates.bis bald
akari
-
Ich würde überhaupt ein einziges .h-File machen, in dem du dann alle anderen inkludierst, die du vorcompiliert haben willst. Dieses musst du dann in jedem .cpp-File als erstes inkludieren. So macht es auch Visual C++ (die nennen es immer StdAfx.h).