Mehrere Klassen in einem Header?



  • Platziert Ihr mehrere Klassen in einem Header (ausgenommen eingebettete Klassen)?
    Macht Ihr Unterschiede, ob es sich dabei z.B. um Interfaces bzw. abstrakte Klassen
    und entsprechende Zugehörigkeiten handelt?
    Oder macht Ihr strenge Trennungen, eine Klasse pro Header?



  • Wenn es sehr kleine Klassen sind, die auch nur im Header implementiert werden, kann das bei mir in seltenen Fällen vorkommen.
    Interfaces sind eigentlich bei immer in einem eigenen Header, weil ich da meist noch etwas mehr Kommentare schreibe, wozu das Interface dient und warum das unbedingt nötig ist.



  • @TauCeti
    Kommt drauf an, wie immer 😉
    Wenn ich mehrere structs oder Klassen habe, die iwie zusammengehören und nur klein sind, dann pack ich die meistens in einen Header. Ich habe mir zB. WINAPI Objekte (Pen, Brush, Font, etc.) weggekapselt und RAII-fähig gemacht, das sind ~10 Klassen in einer Datei. Die .h Datei ist knapp 150 Zeilen lang, die .cpp Datei knapp 600. Das ist für mich ok.



  • @TauCeti sagte in Mehrere Klassen in einem Header?:

    Oder macht Ihr strenge Trennungen, eine Klasse pro Header?

    Nein.

    Oft macht es schon Sinn, aber oft halt auch nicht. Vor allem da ich nicht gerne nested classes verwende (z.B. weil man keine forward-declarations dafür machen kann). Und dann hat man schnell mal ein paar kleine Hilfklassen die zu einer grösseren dazugehören.

    Die Grundidee von 1 Klasse/File ist aber schon gut. Man sollte auf keinen Fall Dinge zusammen in ein File packen die nicht eng miteinander verbunden sind. Und bei 1 Klasse/File gibt's halt keine Grauzone, und wo keine Grauzone ist verschwendet man keine Zeit darüber nachzudenken wo in der Grauzone man sich jetzt befindet 🙂



  • Hallo,

    also ich räumte heute Nachmittag in meinem Code ein wenig auf. Und eine Frage war dann, wenn mehrere Klassen in einem Header deklariert waren, ob und wie diese auf mehrere Dateien verteilt werden können.

    Zur Vereinfachung habe ich dann die CMakeLists.txt umgeschrieben, damit neue Dateien nicht immer in CMakeLists.txt einzeln hinzugefügt werden müssen.

    file(GLOB_RECURSE source_files RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} CONFIGURE_DEPENDS src/*.h src/*.cpp)
    

    Dies wird zwar nicht empfohlen file GLOB:

    Note We do not recommend using GLOB to collect a list of source files from your source tree. If no CMakeLists.txt file changes when a source is added or removed then the generated build system cannot know when to ask CMake to regenerate. The CONFIGURE_DEPENDS flag may not work reliably on all generators, or if a new generator is added in the future that cannot support it, projects using it will be stuck. Even if CONFIGURE_DEPENDS works reliably, there is still a cost to perform the check on every rebuild.

    Gesehen habe ich dies bereits in hier.

    Dann bin ich noch daran eine Verzeichnisstruktur zu etablieren. Dies führte dann aber zu solchen includes.

    #include "../date_convert.h"
    #include "../dates.h"
    

    Weiter versuche ich circular dependency zu vermeiden, muss mich aber damit noch tiefer beschäftigen.





  • Solange die Klassen thematisch zusammengehören, und insbesondere dann wenn man die Klassen nur zusammen nutzen kann, sollten sie auch zusammen deklariert bzw. implementiert werden.


Log in to reply