Warum sollte man die header erst in der cpp-datei inkludieren?
-
unwissenderwissbegieriger schrieb:
So so, werden sie das? Ich dachte das wird durch ifndef verhindert? Sprich einmal "reinkopiert", danach ist gut.
Es geht hier um mehrere Kompilierungseinheiten, da wird jedes mal neu "reinkopiert". Und dass das nicht passiert macht man es in die .cpp. So wird es nur in die eine Einheut "reinkopiert"...
Hört sich lustig an... "reinkopiert"
-
Das klingt für mich aber nicht wirklich plausibel, bisher war das bei allen Projekte so die ich mir angeschaut habe
quake, blood, jagged alliance 2 usw.
Soll das der einzige Grund sein?
-
Also dann machs eben nicht so.
Du willst nicht geholfen werden.
-
unwissender: weitere gründe siehe mein editierter post
-
unwissender324 schrieb:
Das klingt für mich aber nicht wirklich plausibel, bisher war das bei allen Projekte so die ich mir angeschaut habe
quake, blood, jagged alliance 2 usw.
Soll das der einzige Grund sein?
Das die Unsitte einen "Ich include hier alles was ich brauche"-Header zu benutzen weit verbreitet ist, ist kein gegenbeweis. Es gibt viele weit verbreitete Angewohnheiten die trotzdem nicht gut sind.
Selbst mit precompiled Headerfiles sind die Buildzeiten durchaus teilweise deutlich länger, als wenn jede Komponente nur includet was sie benötigt. Grosse Firmen kompensieren die durch Faulheit entstehenden Buildzeiten manchmal mit parallelisierten Builds im Netz, so das es dort nicht so auffällt, aber die Option hat man selber eher nicht (wenn man nicht über einen Maschienenpark verfügt). In einem Großprojekt in dem ich eine Zeitlang war, hat das einiges gebracht. (Die Buildzeiten waren da allerdings auch jenseits dessen was man normalerweise so erlebt.)
Zudem kann man bei sorgsamer Pflege der Includes auch auf einen Blick sehen, was eine Komponente so alles benötigt. Das ist vor allem bei non-standard-Includes wie third-party-Libs eine schöne zusätzliche Dokumentation wenn man das Projekt pflegen und neuen Gegebenheiten anpassen muß.
Tauchen in diesem Wollmilchsau-Header dann noch so Sachen wie eigene tools in einer Art utility.h auf, so baut sich das system jedesmal den Oberwolf, wenn man darin was ändert, selbst wenn das nur selten gebraucht wird.
-
unwissenderwissbegieriger schrieb:
Ich glaub so ganz die Antwort auf meine Frage war das nicht? Ich meine ich habs bisher so gemacht
// Irgendeine Header.h #include <map> #include <list> #include <queue> #include <string> #include <fstream> using namespace std;jetzt haben mir 3 Leute erzählt man packt diese includes, außer man braucht sie natürlich schon für Klassenvariablen, in die zugehörige cpp datei.
Warum?
Genau das hab ich dir doch in meinem Post erklärt
MfG
-
unwissenderwissbegieriger == Troll
-
Nö, die einzigehalbwegs nachvollziehbare Erklärung war IMHO die von pumuckl. Den Rest kann man doch nicht verstehen, wenn man den Grund noch nicht weiß.
-
Michael E. schrieb:
Nö, die einzigehalbwegs nachvollziehbare Erklärung war IMHO die von pumuckl. Den Rest kann man doch nicht verstehen, wenn man den Grund noch nicht weiß.
Danke, ich bin nämlich definitiv kein Troll.
-
damit es schneller compiliert.
unwissenderwissbegieriger schrieb:
?! Klingt komisch, begründung?
in meinem aktuellen programm habe ich 14 *.cpp-dateien und 13 *.h-dateien.
das compilieren dauert 14 sekunden. (ok, mingw und lahmer rechner, aber die ergebnisse lassen sich übertragen auf schnelle rechner und schnele compiler, wenn man mehr dateien hat.)ich inkludiere sehr wenig. aber zwei cpp-dateien müssen dicke dinger inkludieren. ein dickes ding ist die <windows.h> und das andere <vector>.
die beiden cpp-dateien, die dicke dinger inkludieren brauchen 11 sekunden und die 11 anderen cpp-dateien brauchen 3 sekunden. also sind bei mir die cpp-dateien, die dicke dinger inkludieren um den faktor 20 langsamer.stell dir vor, ich würde in jeder cpp-datei die <windows.h> inkludieren. ich müßte auf das ganze projekt nicht mehr wie bisher 14 sekunden sondern 71 sekunden warten.
es gibt (eigene) header, die ich von jeder cpp-datei aus inkludiere. diese header dürfen die <windows.h>(fettester brocken überhaupt) nicht inkludieren und auch nicht die <iostream>(zweitfettester), weil sonst jede meiner cpp-dateien die dann über umweg auch inkludiert und alles langsam ist.
ok, normalerweise lasse ich nicht alle cpp-dateien compilieren, es dauert also nicht 71 sekunden, normalerweise arbeite ich ja nur an einer cpp-datei und immer nach ein paar änderungen lasse ich compilieren, um zu sehen, ob ich mch wieder vertipp habe, und auch mal zum ausprobieren. aber auch da ist der unterschied zwischen 5 sekunden und 0,3sekunden etwas ganz erhebliches. ich mag nicht immer 5 sekunden warten, um die fehlermeldungen zu bekommen.