C ++: Nachteile beim Schreiben von ganzen Klassen in Header-Dateien für kleine Projekte?

8

Nur eine Stilfrage ...

Ich bin ein Low-Indie-Game-Entwickler, der selbst arbeitet, und ich entwickelte, was mir gesagt wurde, ist eine "schlechte" Angewohnheit, ganze Klassen in meinen Kopfzeilen zu schreiben. Einige der Vorteile, die ich kenne .h / .cpp Datei Combos haben, sind sie ermöglichen Code in Compilation Chunks aufgeteilt werden, die nicht neu kompiliert werden müssen, solange sie unverändert bleiben. Und ermöglicht die Trennung der Schnittstelle von der Implementierung.

Aber keines dieser Dinge bringt mir etwas, denn ich bevorzuge es, meine Implementierung an einem Ort zu haben, an dem ich sie leicht verbessern, ändern, lesen kann. Und meine Kompilierzeiten sind fast augenblicklich (2-4 Sekunden, 15 wenn ich SFML oder Box2D auf ihre neuesten Versionen aktualisierte und sie auch neu kompiliert werden müssen)

Die Codierung hat mir sehr viel Zeit erspart, und da es weniger Dateien gibt, fühlt sich mein Code weniger überwältigend an.

Aber im Hinblick darauf und im Allgemeinen gibt es einen zwingenden Grund, die Datei "file.cpp" für jedes "file.h" Setup für ein kleines Projekt zu befolgen, bei dem die Kompilierzeit und die Trennung der Schnittstellen / Implementierungen keine Prioritäten sind?

    
Anne Quinn 07.03.2011, 04:14
quelle

3 Antworten

6
  

Gibt es einen zwingenden Grund, der Datei "file.cpp" für jedes "file.h" Setup für ein kleines Projekt zu folgen, bei dem die Kompilierzeit und die Trennung der Schnittstellen / Implementierungen keine Prioritäten sind?

Nein; Es ist nichts falsch daran, Klassen und Funktionen in Header-Dateien zu definieren, insbesondere nicht in kleinen Projekten, bei denen die Kompilierungszeiten keine Rolle spielen.

Was es wert ist, mein aktuelles, laufendes Hobbyprojekt hat 33 Header-Dateien und eine einzelne .cpp-Datei (ohne Unit-Tests). Das liegt hauptsächlich daran, dass fast alles eine Vorlage ist.

Wenn Sie ein riesiges Softwareprojekt haben oder wenn Sie Ihren Code in eine Bibliothek kapseln müssen und tatsächlich die Modularität benötigen, dann könnte es sinnvoll sein, Code aus einer Header-Datei aufzuteilen. Wenn Sie einige Implementierungsdetails ausblenden möchten (z. B. wenn Sie eine unschöne Kopfzeile haben, die Sie nicht an anderer Stelle in Ihr Projekt einfügen möchten, z. B. WinAPI-Header), ist es sinnvoll, den Code in eine separate Quelldatei aufzuteilen um diese Details zu verbergen. Sonst könnte es nur eine Menge Arbeit für nicht viel Gewinn sein.

    
James McNellis 07.03.2011, 04:24
quelle
2

Ich denke, sowohl die Kompilierzeit als auch die Schnittstellen- / Implementierungstrennung sind gute Gründe. Auch wenn das erstere im Moment kein Problem ist, wird es in den meisten anständigen Projekten zu einem Problem.

Aber da Sie nach anderen Gründen gefragt haben, denke ich, dass es die Abhängigkeiten verringert. Die Implementierung Ihrer Klasse erfordert wahrscheinlich mehr #includes als die Schnittstelle. Wenn Sie jedoch die Implementierung in die Header-Datei einfügen, ziehen Sie diese Abhängigkeiten mit dem Header. Dann hat jede andere Datei, die diese enthält, auch diese Abhängigkeiten.

Es gibt jedoch keine allgemeingültige Regel. Und einige Klassen (besonders "kleine") sind wahrscheinlich am besten vollständig in einem Header platziert.

    
dappawit 07.03.2011 04:25
quelle
1

Was Sie tun, klingt für Ihre Situation sinnvoll. Zwei andere mögliche Probleme:

  • eine Definitionsregel
  • testen

Wenn Sie nur eine cpp-Datei und ein paar Dutzend Header haben, können Sie es sich leisten, bei der Definition einer Regel unvorsichtig zu sein (vorausgesetzt, Sie haben Include-Wächter). Dies könnte Sie beißen, wenn Sie eines Tages das Bedürfnis haben, das Projekt als eine Anzahl von Übersetzungseinheiten zu kompilieren / zu verknüpfen. Das könnte auf nicht so offensichtliche Weise geschehen, zum Beispiel wenn man anderen Leuten eine Bibliothek zur Verfügung stellen möchte, die sie mit ein paar Headers erstellen sollen. implizit (innerhalb der Klasse definiert) oder explizit (mit dem Schlüsselwort) inline functions ist in Ordnung, aber hüte dich vor anderen. Übliche Regeln für Variablen etc ..

Zum Testen: Manchmal hilft es, mindestens eine Token-CPP-Datei zu haben, die die .h-Datei enthält und Compiles abruft. Nur so können Sie frühzeitig warnen, wenn der Inhalt einer Kopfzeile nicht "alleine stehen" kann zu einem vergessenen #include. Wenn Sie CPCP-Dateien pro Header haben, dann tötet das zwei Vögel usw. Wenn Sie nicht möchten, dass Tests auf dieser Ebene ausgeführt werden, und kleine Fehler in Abhängigkeits-Bugs reaktiv bereinigen, dann können Sie es auch vergessen.

    
Tony Delroy 07.03.2011 04:42
quelle

Tags und Links