Mahlzeit,
mich würde mal interessieren wie ihr in objektorientierten Sprachen,
allen vorran C++, eure Sourcen organisiert.
Ich komme aus der Embedded-Ecke, und dort eher C als C++. Da hat sich im
beruflichen Umfeld (und dadurch auch daheim) eingebürgert, jedes Modul
bekommt einen Ordner myModul, darinnen findet sich eine myModul.h und
myModul.c. Evtl noch zusätzliche Dateien, die Konfigurationen enthalten.
Ich habe bei meiner Arbeit mit C++ versucht, dieses Schema
beizubehalten. Also eine .cpp und eine .h für jede Klasse. Java verlangt
dies imho sogar explizit, dass eine Klasse so heißt wie die dazugehörige
Datei.
Da stellt sich aber sehr schnell heraus dass man mit dem Ansatz nicht
weit kommt. In einen C++ Projekt finden sich viel mehr Klassen als
"Module" in einem C Projekt. Also hab ich eher geschaut dass ich nur die
Klasse im Header bekannt mach die nach außen sichtbar sein soll,
Hilfsklassen kommen ins .cpp File. Da stören mich schonmal die nötigen
Vorward-Declarations die nötig sind um die Header sauber zu halten.
Aber es geht weiter: werden Hilfsklassen zu groß bietet es sich an, sie
dennoch auszulagern und ihnen extra Dateien zu spendieren. Aber man will
ja nicht alles in einem Ordner haben, weswegen ich dann solche
Strukturen geschaffen habe:
projectroot/myClass/myHelperClass, worinnen dann die Dateien der
Hilfsklasse liegen.
Was aber wenn ich eine mySecondClass habe, die ebenso im projectroot
liegt, die myHelperClass benutzen will? Dann muss ich meine
Ordnerstruktur ändern:
projectroot/myClass
projectroot/mySecondClass
projectroot/myHelperClass
Jetzt liegt aber myHelperClass leveltechnisch gesehn viel zu weit
"oben", denn sie sollte eigentlich nicht direkt benutzt werden.
Lange Rede, kurzer Sinn: ich hab keinen Plan wie ich mein C++ Projekt
organisieren soll. Ich weiß nicht, was ich in die Header packen soll und
ich weiß nicht wie ich die Klassenhierachie in der Ordnerstruktur
abbilden kann.
Könnt ihr mir da generelle Tipps geben?
Oder gibt es da vielleicht eine Übersicht über bewährte Techniken?
(auf uC.net gibts ja zumindest einen Wiki Artikel was C Sourcen und
Header betrifft, sowas in der Richtung).
Und wie gesagt, eine sinnvolle Ordnerstruktur würde mich auch
interessieren.
Grüße!
Michl schrieb:> Also eine .cpp und eine .h für jede Klasse.
Genau so. Ganz selten anders. Allerdings nicht jeder Klasse nochmals in
einen eigenen Ordner, sondern Ordner nach Modulen/libs/sonstigen
Einheiten.
Oliver
Beachte weiterhin, dass es innerhalb der Quelltexte auch noch die
Namespaces als hirarchische Ordnungseinheit gibt. Diese lassen sich auch
dafür einsetzen, entsprechende Modulhirarchien abzubilden. Ob man nun
versuchen sollte, Verzeichnis- und Namespace-Hirarchie aufeinander
abzubilden, kann sicherlich auch länglich diskutiert werden.
Ich handhabe es üblicherweise auch so, dass kleinere Hilfsklassen nicht
in separate Dateien ausgelagert werden. Sobald jedoch die Funktionalität
von mehreren Modulen genutzt werden, werden die Hilfsklassen ausgelagert
und ggf. Namespaces angepasst.
Oliver schrieb:> Michl schrieb:>> Also eine .cpp und eine .h für jede Klasse.>> Genau so. Ganz selten anders. Allerdings nicht jeder Klasse nochmals in> einen eigenen Ordner, sondern Ordner nach Modulen/libs/sonstigen> Einheiten.>> Oliver
Ich würde eher formulieren: trenne das, was getrennt verwendet werden
kann und halte das zusammen, was zusammen verwendet werden muss. Nach
meiner Erfahrung ist es dann eher selten, dass eine Klasse in einer
Datei alleine bleibt. Es macht zum Beispiel wenig Sinn, einen
STL-konformen Container zu schreiben und die spezifischen Iteratoren in
eigene Dateien auszulagern, nur um einer Regel zu genügen. (Es sei denn,
ich kann die gleichen Iteratoren für mehrere Container nutzen, dann
gehen sie zwecks Nachnutzung natürlich in eine eigen Datei,
wahrscheinlich reicht dann aber auch eine für alle.) Also, grundsätzlich
ist die Richtlinie gut, nimm sie aber nicht zu wörtlich. Es ist eben nur
eine Richtlinie.
/[projectname]
-- /src (.cpp, .c)
-- /inc (.h)
-- /lib (.dll, .o, .so, eigene libs)
-- /bin ( kompiliertes, command line tools)
-- /data ( assets, ... )
-- ...
wobei src und inc würde ich noch unterteilen wie oben steht nach dem
sinn, je nachdem was du für ein projekt machst
/helpers, /utils, /models, /views, /interface, /gui, ...
Mark 99 schrieb:> Wenn du es ganz genau wissen willst (abzüglich ein paar veralteter> Ideen):>> Lakos: Large-Scale C++ Software Design> http://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633620
Das Buch ist von 1996... damals hat man Software noch auf Papierkarten
geschnitzelt
Geh mal lieber auf GitHub und stöbere da durch grössere Projekte, da
siehst du die Strukturen die sich etabliert haben heutzutage. Wobei es
nicht zwingend notwendig ist, ... je nach Projekt ist die sinnvolle
Struktur anders und das kommt erst mit der Erfahrung.
Doc schrieb:> Das Buch ist von 1996...
Und?
> damals hat man Software noch auf Papierkarten> geschnitzelt
Geht's noch?
Immer diese dauerbekifften Kids, die alles älter als ein Jahr schon als
"classic" bezeichnen und alles älter als fünf Jahre für Dreck halten.
Mark 99 schrieb:> Geht's noch?>> Immer diese dauerbekifften Kids, die alles älter als ein Jahr schon als> "classic" bezeichnen und alles älter als fünf Jahre für Dreck halten.
Hallo Mark,
wer hier bekifft und ein Kid ist, ist noch die Frage.
Da direkt mit Beleidigungen anfangen zeugt nicht von deiner erwachsenen
nüchternen Seite.
Seit 1996 sind keine 5 Jahre, sondern 18 Jahre vergangen, und damals
waren andere C/C++ Standards, die wiederrum auswirkungen auf sinnvolle
Projektstrukturen hatten. Der Threadersteller kann sicher noch von dir
vorgeschlagenes Buch lesen, nur "sinnvoller" wäre natürlich auf die
heutige Technik zu schauen.
Gruß
Doc schrieb:> Seit 1996 sind keine 5 Jahre, sondern 18 Jahre vergangen, und damals> waren andere C/C++ Standards, die wiederrum auswirkungen auf sinnvolle> Projektstrukturen hatten.
Aber sie sind nicht so groß, dass zentrale Themen damit ungültig würden.
Fred Brooks 'Mythical Man Month' stammt aus 1975. Trotzdem werden auch
heute noch genau die gleichen Fehler gemacht, die damals schon
gebrandmarkt wurden.
http://en.wikipedia.org/wiki/The_Mythical_Man-Month