Warum sollte man die header erst in der cpp-datei inkludieren?

pumuckl

Im übrigen: falls du in einer Headerdatei eine Klasse erwänst, aber nicht benutzt (also z.B. ein Datenelement von dem Typ hast, aber nicht die Klassenmethoden benutzt), dann sollte man die zugehörige Headerdatei in der eigenen Headerdatei garnicht erst einbinden.
Ferner verweise ich wiedermal gerne auf mein Lieblingsbuch: Scott Meyers' "effective C++" (auf deutsch: "effektiv C++ programmieren") bietet auch zu dem Thema Kompilationsabhängigkeiten und includes ein eigenes Kapitel und ist auf jedenfall das Geld wert (kostet momentan afaik ca. 17 Euro)

was die unterscheidung von includes in header oder .cpp angeht:
meistenteils werden mit den Includes neue Klassenschnittschtellen geladen, die mit der selbsterstellten Klassenschnittstelle nichts zu tun haben (sollten). Die Fremdheader sind also Implementationsdetails, die in einer headerdatei nichts verloren haben. Man stelle sich vor, man hat in der neuen KLasse ein Datenmember vom typ T. Als vernünftiger Programmierer macht man das Datenmember private und stellt ggfs. get/set-Methoden zur Verfügung. Wie die Implementierung meiner KLassenmethoden die Methoden von T benutzt, geht den klienten nichts an, er muss höchstens wissen, dass es die Klasse T gibt. Deshalb reicht eine einfache Deklaration in der Headerdatei:

class T;

Mehr muss der Klient nicht wissen. Sollte er die get/setter-Methoden benutzen wollen, so muss er sich selbst darum kümmern, die Schnittstelle von T zu includieren. Das ist das Prinzip der kapselung udn des information hiding.

Folgendes Szenario:
Ich benutze die Klasse T nur, um intern meine Daten zu verwalten. Der klient braucht sie eigentlich nicht. Trotzdem hab ich in meine MyClass.hpp ein "#include T.hpp" hineingeschrieben, statt der oben gezeigten einfachen Deklaration. Ich habe jetzt festgestellt, dass ich meine Klasse T noch erweitern möchte, und schreibe sie mitsamt header etwas um. Im normalfall htte ich nur T und MyClass neu kompilieren müssen, weil ja MyClass.hpp unverändert ist und alles, was davon abhängt also auch. weil ich aber T.hpp inkludiert hab und die sich geändert hat, muss alles, was direkt oder indirekt MyClass.hpp inkludiert, auch neu kompiliert werden. Und da ich ja bei der T.hpp mit dem include so großzügig war, war ich das andernorts mit sicherheit auch, und muss die ganze Welt neu kompilieren. Viel Spaß...

FireFlow

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?

FireFlow

Also dann machs eben nicht so.

Du willst nicht geholfen werden.

pumuckl

unwissender: weitere gründe siehe mein editierter post

Hutzli

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.

Saiyaman

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

Michael E.

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.

volkard

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.