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, ...
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
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.
Michl schrieb: > Könnt ihr mir da generelle Tipps geben? > Oder gibt es da vielleicht eine Übersicht über bewährte Techniken? Einige Infos gibt es z.B. hier: Bjarne Stroustrup's C++ Style and Technique FAQ http://www.stroustrup.com/bs_faq2.html Look at the JSF air vehicle C++ coding standards. http://www.stroustrup.com/JSF-AV-rules.pdf
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
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.