Mehrere Übersetzungseinheiten
-
Hallo zusammen,
Ich höre immer wieder, wie viele Leute mit mehreren Übersetzungseinheiten arbeiten. Häufig wird gesagt, bei Klassen sollte man die Deklaration in eine Headerdatei und die Definition der Memberfunktionen in CPP-Dateien schreiben.Bis jetzt hatte ich eigentlich meistens nur eine Übersetzungseinheit, halt dort wo
main()steht. Den Rest binde ich immer in H-Dateien ein.Was ist schlecht an meiner Vorgehensweise bzw. welche Vorteile bietet es, wenn man mehrere CPP-Dateien erstellt? Ich habe auch schon gehört, dass man dann viel mehr aufpassen muss wegen ODR und solchen Sachen... Was ist also ausschlaggebend?
-
Hi,
Wenn du an größeren Projekten (~>10000 Zeilen Code) arbeitest, wirst du mehrere ÜE (wenn du sie so nennen willst, besser wäre meiner Meinugn nach Module) brauchen.
Vorteil davon:
Wenn sich in einer Datei etwas ändert, brauchst du nur das entsprechende Modul neu kompilieren, der rest bleibt unverändert. (Google nach Vorteieln von dynamischen gegenüber statischen Libs, das ist sozusagen nur einen Level höher)
Nachteil:
Der Compiler kann nicht mehr über die Funktionen hinweg optimieren. Bei Hochperformance-Anwendungen darfst du also nicht functions in anderen Object-Files callen.mfg, Hans
-
Das heisst, die Kompilierzeit ist der einzige Vorteil? Weil bei meinen Projekten dauert das eh nur 10 Sekunden, von daher ist es nicht so tragisch, wenn ich immer alles kompiliere.
Sonst hat es keine Nachteile, wenn ich nur eine CPP-Datei habe?
-
Na ja, wenn 100 Progrmamierer an einen Projekt arbeiten, muss ja auch jede Arbeitsgruppe ein eigenes Modul haben, da sonst inkonsistente Versionen zusammenkommen können (auch mit Versionierungssoftware wie SVN).
Wenn du den ganzen Linux-Kernel in ein Modul schreibst, kannst du ewig warten, bis der fertig ist.
Außerdem zwingen dir machen Frameworks wie wxWidgets und besonders die RAD-GUI-Designer (fast) mehrere Module auf.mfg, Hans
-
Okay, danke für die Erläuterungen.
Und was hat es jetzt mit der Trennung bei Klassen (Methodendeklarationen in Headern und -definitionen in CPP-Dateien) auf sich?
-
Du brauchst sowieso die Klassendefinition in nem Header damit deine anderen Module wissen wie die "Aussehen". Um Fehler zu vermeiden und dir Arbeit zu sparen, kannst du das ganze auch gleich in einem machen, den du in allen Modulen einbindest.
mfg, Hans
:schland:
-
Inzwischen hab ich mir die Thematik noch ein bisschen genauer angeschaut. Trotzdem habe ich den Eindruck, man erhält einige Probleme bei mehreren CPP-Dateien. Man muss immer schauen, dass Bezeichner nur einmal definiert sind, bei Klassen muss man genau auf
inline-Methoden achten und beispielsweise Templates sind schwierig zu implementieren (das Schlüsselwortexportwird ja nicht immer vollständig unterstützt). Kann auch sein, dass ich mich irre, korrigiert mich bitte.Also lohnt es sich schlussendlich trotzdem (auch wegen der bisher genannten Argumenten wie Konsistenz und einzelne Kompilierung), den Code auf mehrere Übersetzungseinheiten zu verteilen?
-
Nexus schrieb:
Also lohnt es sich schlussendlich trotzdem (auch wegen der bisher genannten Argumenten wie Konsistenz und einzelne Kompilierung), den Code auf mehrere Übersetzungseinheiten zu verteilen?
Ich würde es dringend empfehlen. Bei grösseren Projekten fördert sowas extrem die Übersicht und besser du fängst jetzt damit an, als das du dich später umgewöhnen musst.
Ein so grosses Problem ist es im übrigen nicht. Wenn man es regelmässig anwendet, passiert alles voll automatisch. Ich habe seit Ewigkeiten keine Probleme mehr gehabt mit Mehrfachdefinitionen oder sonstigem. Der Gewinn den ich davon habe ist aber extrem! Ich würde meinen Quellcode nicht mehr verstehen, wenn da nur ein .cpp File wäre.
Die templates kann man im übrigen vollständig im Header belassen oder du kannst sie in ein cpp auslagern und dann im Header includen. Also alles ohne export oder sowas.
Was dein Problem mit inline Klassenfunktionen ist, verstehe ich nicht ganz. Inlineklassenfunktionen kann man ruhig im Header, bzw. der Klassendeklaration, belassen, so werden sie auch automatisch zu inline funktionen, ohne das Schlüsselwort zu verwenden. Und man erkennt auch schnell, ob es nicht sinnvoller wäre, die inline Funktion in eine normale zu verwandeln, weil sie zu dick im Header ist
Grüssli
