Was passiert wenn ich einfach alles in Headerdateien schreibe?
-
HeaderHead schrieb:
Was mich an C++ aber an C nervt, ist die Geschichte mit den Header und Implementierungs-Dateien. Was für einen Nachteil, außer der höheren Kompilierungszeit, habe ich eigentlich wenn ich gleich alles in die Headerdatei schreibe, so wie bei anderen Sprachen? Zur Info, ich code nur allein an meinen Projekten, ist einfach entspannter.
Kannste machen.
Ganz praktisch ist aber auch, wenn die IDE eine Klassenansicht hat statt nur der Dateiansicht, dann isses einem wurst, wo die Funktion genau steht. Irgendwann mal, wenn die Klasse schon ziemlich stabil ist, kann man die Implementierungen auslagern.
So super-fette Brocken wie die <windows.h> meide ich gerne, also wenn ich kann, kommt eine eigene CreateFile her, die die von Windows aufruft, für die ich aber keine fetten Header brauche.
-
Das ist natürlich eine tolle Idee, erstmal alles in eine Header-Datei schreiben und erst wenn die Klasse wirklich fertig ist in Header und Implementierung teilen. Ich habe nämlich bis jetzt für jeden Kack immer eine Header und Cpp Datei geschrieben, auch wenn die IDE einen da einiges Abnimmt ist es doch stressig und stört meinen Workflow.
Bei Abhängigkeiten sehe ich kein Problem, wenn ich sowas mal brauche schreibe ich halt eine extra Deklaration des gebrauchten Typs davor. Ist ja nicht so dass man sowas ständig hat.
-
HeaderHead schrieb:
Was für einen Nachteil, außer der höheren Kompilierungszeit, habe ich eigentlich wenn ich gleich alles in die Headerdatei schreibe [...]
hängt u.a. von der Projektgröße ab. Wenn es einem nichts ausmacht, nach einer vergessenen geschweiften Klammer in einer main.h mit 1 mio+ LOC zu suchen ... Für jeden Testlauf das gesamte Projekt rebuilden zu müssen, dürfte ab einer bestimmten Projektgröße auch nicht gerade Zeit (und Kaffee) sparen.
-
Wir reden hier von mehreren Headerdateien.
-
Nexus schrieb:
BigSource schrieb:
Es ist doch für einen Compiler eh besser wenn er den gesamten Source auf einmal sieht, als diesen gestückelten Mist, erst so kann er richtig optimieren.
Für irgendwas gibts den Linker.
Naja, der Linker bekommt ja schon Maschinencode vorgesetzt.
Zum Optimieren hat man aber lieber eine Zwischendarstellung.
Bezweifle dass ein Linker so gut zb. über Inlining entscheiden kann wie es der Compiler könnte wenn er alle Definitionen vorliegen hat.Hat nen Grund warum zb. SQLite mit einer normalen Header/Source Trennung entwickelt aber als einzige, riesige Sourcedatei vertrieben wird: Es ist in der Praxis einfach schneller.
-
HeaderHead schrieb:
Wir reden hier von mehreren Headerdateien.
eigentlich nicht:
HeaderHead schrieb:
Was für einen Nachteil, außer der höheren Kompilierungszeit, habe ich eigentlich wenn ich gleich alles in die Headerdatei schreibe,
-
Überschrift
Was passiert wenn ich einfach alles in Headerdateien schreibe?
Das im Text ist ein Schreibfehler. Mir geht es darum Nachteile zu ergründen, wenn ich anstelle logger.cpp und logger.h nur logger.h habe. Klar muss man Vorwärstdeklarationen bei einigen wenigen Klassen betreiben, dies ist aber nicht wirklich ein Problem.
offtopic:
Ich entwickle von der Pike auf allein, muss kein Teamwork machen und es soll auch keiner meine Sachen benutzen können. Beruflich habe ich ein paar Jahre im Team mit Lecacy Code(allerdings eine anderen Programmiersprache) zu tun gehabt und ich fand es zum Kotzen. Programmieren macht mir nach wie vor Spaß, aber nur wenn da kein anderer an meinem Code rumpfuscht und schon gar nicht mag ich es, mich durch fremden Code zu wühlen. Ne, das ist nicht mein Ding gewesen.
-
@Ethon: wenn das tatsächlich ein Problem ist, bieten Compiler Optionen wie Linkzeit-Codegenerierung (LTCG) an, wodurch ein Teil der Compiler-Aufgaben auf den Linker delegiert wird.
Meine persönliche Erfahrung ist aber gerade im Bezug auf Inlining, dass viele falsche Vorstellungen davon haben. Wie oft hört man die undifferenzierte Aussage, Inlining führe zu schnellerem Code? Spätestens wenn die Code-Qualität sichtlich darunter leidet (alles wird im Header definiert, Abhängigkeiten werden daher auch in den Header gezogen, Änderungen an der Implementierung erfordern ständiges Neukompilieren, alles dauert länger), müssen derartige Mikrooptimierungen gerechtfertigt sein.
Das Schlüsselwort
inlinesollte primär zur Erfüllung der ODR und nicht zur Optimierung eingesetzt werden.Zudem: Was bei mehreren Übersetzungseinheiten langsam ist, ist das ständige Parsen der gleichen Header. Wenn der gleiche Code Dutzende Male gelesen wird, dauert das natürlich. Vorkompilierte Header können in solchen Szenarien einiges ausmachen.
-
inline ist extrem wichtig, guck die mal Libs wie glm an, wo sogar noch inline mit SSE eine Menge rausgeholt wird. Da kann man durch aus seinen Code um Faktor zehn beschleunigen. Optimierungen vom Compiler bringen in der Regel nicht viel, per Hand Optimierung bringt dagegen eine Menge. Das geht sogar bis zum Faktor 30 wenn für jeden CPU-Typ der Algo angepasst wird. Da wird dann vorher geschaut wie z.B. das Caching der jeweiligen CPU aussieht und danach dann andere Code included. Das bringt eine ganz schöne Menge. Eine Vorlesung dazu findest du hier:
Eingesetzt werden die Ergebnisse dann z.B. hier, wenn das alles nur ein paar Prozent bringen würde, würden da nicht so viele Entwickler so viel Zeit investieren, das bringt alles schon eine ganze ganze Menge:
https://software.intel.com/en-us/intel-ippHier wird leider oft so getan, als dass man ja eh nicht viel besser optimieren kann als der Compiler. Das ist total FALSCH!
-
inlinergood schrieb:
inline ist extrem wichtig, guck die mal Libs wie glm an, wo sogar noch inline mit SSE eine Menge rausgeholt wird. Da kann man durch aus seinen Code um Faktor zehn beschleunigen. Optimierungen vom Compiler bringen in der Regel nicht viel, per Hand Optimierung bringt dagegen eine Menge. Das geht sogar bis zum Faktor 30 wenn für jeden CPU-Typ der Algo angepasst wird. Da wird dann vorher geschaut wie z.B. das Caching der jeweiligen CPU aussieht und danach dann andere Code included. Das bringt eine ganz schöne Menge. Eine Vorlesung dazu findest du hier:
Eingesetzt werden die Ergebnisse dann z.B. hier, wenn das alles nur ein paar Prozent bringen würde, würden da nicht so viele Entwickler so viel Zeit investieren, das bringt alles schon eine ganze ganze Menge:
https://software.intel.com/en-us/intel-ippHier wird leider oft so getan, als dass man ja eh nicht viel besser optimieren kann als der Compiler. Das ist total FALSCH!
Nein. Er zeigt doch gerade, daß selbst beim Hammer-Problem der fft der Automat schon besser ist als der Mensch. Siehe Minute 32. Über inline sagt er gar nix.