Momentan programmiere ich in Java und benutze Maven ziemlich oft. So habe ich mich an die Namensschemata und Ordnerstrukturen gewöhnt, die ich in den letzten 4 oder 5 Jahren benutzt habe.
Da ich gerade C ++ gelernt habe, merke ich, dass ich keine Ahnung habe, wo ich alle meine Dateien ablegen soll. Soll ich alles nach Namespace oder nach welcher Stufe gliedern? Wo würde ich zum Beispiel eine Reihe von Dateien für die Benutzeroberfläche aufbewahren, wie etwa Dateien, die beim Speichern von Daten helfen sollen?
Gibt es irgendwelche Standards für diese Art von Dingen?
Natürlich gibt es keine definitive Antwort auf diese Frage. Ich suche einfach einen guten Führer. Ich möchte nicht anfangen, C ++ zu lernen, indem ich zu viel Zeit damit verbringe, mir Gedanken darüber zu machen, wie meine Dateien angelegt sind. Ich hätte lieber ein paar gute Modelle und komme einfach zur Programmierung.
Das Folgende ist ziemlich typisch ...
%Vor%Grundsätzlich sind Unterordner für Unterprojekte für größere Projekte üblich, aber meistens hat ein bestimmtes Projekt Ordner für src, include usw. Ein Ordner für jede Build-Konfiguration ist üblich und hält die obj-Dateien und andere Zwischenprodukte in einem Unterordner davon eine gute Idee. Es mag verlockend sein, Unterprojektordner in obj-Ordner zu platzieren, aber das ist normalerweise nicht nötig - die obj-Ordner müssen nicht gut organisiert sein, so dass nur ein Dateinamenskonflikt besteht und die beste Lösung darin besteht, eindeutige Quelldateinamen zu haben innerhalb (mindestens) jedes Projekts.
Die "include" Ordner sollten IMO nur Header enthalten, die von anderen Projekten eingeschlossen werden - interne Header gehören in den "src" Ordner.
Das Einfügen von UI-Material in einen separaten Ordner ist keine schlechte Idee, wenn es groß genug ist. Ich habe UI-Sachen als separates, statisch verknüpftes Top-Level-Projekt gesehen, und ich meine hier app-spezifisch, nicht (z. B.) wxWidgets. In der Regel ist diese Unterteilung jedoch Teilprojekt wenn es sich lohnt, überhaupt zu trennen. Wie Sie Teilprojekte unterteilen, hängt eher von anwendungsspezifischen Blöcken ab, und hängt davon ab, ob UI-Elemente am besten als separater Block oder als separate Blöcke mit taskspezifischer Logik behandelt werden.
Namespaces sind nicht die am häufigsten verwendeten Sprachfunktionen, möglicherweise weil viele Leute "using" so oft verwenden, dass sie keinen großen Unterschied machen. Ein Namespace für ein Hauptbibliotheksprojekt ist sinnvoll, aber die Zuordnung von Unterordnern zu Namespaces 1: 1 habe ich nicht gesehen. Ich persönlich habe einen Namespace, der den größten Teil meines Bibliothekscodes umfasst, mit ein paar Sub-Namespaces für Dinge, die im Allgemeinen selten verwendet werden, aber an einigen Stellen sehr häufig verwendet werden (z. B. "bitweise" Namespaces). Die Sub-Namespaces sind auf Single-Source- / Header-Paare beschränkt, sodass keine Unterordner benötigt werden. Der Großteil der bibliotheksspezifischen Auswahl erfolgt durch Einfügen der richtigen Kopfzeile - mit der Ausnahme, dass ich das Los in der Regel sowieso über einen Hauptprojekt-Header der obersten Ebene einbinde.
Namespaces sind im Grunde eine Möglichkeit, Namenskonflikte zu vermeiden. Sie assoziieren nicht unbedingt mit Abstraktionen oder funktionalen Blöcken oder irgendetwas. In einem bestimmten Projekt ist es wahrscheinlich besser, wenn Sie sicherstellen, dass die Namen nicht in Konflikt stehen. Wie beim Namespace "std" ist es in Ordnung, ein Los in einen Namespace zu schreiben.
Wie Sie jedoch sagen, ist dies keine definitive Antwort - es gibt natürlich kleinere Abweichungen und ganz andere Ansätze.
Bei kleinen Projekten gruppiert mein Team alle Dateien durch eine Link-Einheit, dh Bibliothek, DLL, EXE. Wenn die Einheit sehr groß ist, werden wir die Dateien manchmal nach Funktionseinheit oder Subsystem aufteilen, so dass, wenn Sie eine Komponente bearbeiten müssen, sie sich im Allgemeinen an der gleichen Stelle befinden.
Ich breche meine Projekte nach Thema, ein Verzeichnis für Thema:
%Vor%Meine Erfahrung mit C und C ++ hat mir gezeigt, dass header und source -Dateien im selben Verzeichnis sein sollten. Oft ist es schwieriger, eine Headerdatei zu finden, wenn sie sich nicht im selben Verzeichnis wie die Quelldatei befindet.
Ein Verzeichnis (Ordner) pro Konzept ist eine gute Idee. Jedes Konzept, das komplex oder zusammengesetzt ist, sollte in mehrere Ordner oder Konzepte aufgeteilt werden.
Ich habe auch gelernt, Bibliotheken zu machen. Ich verwende Bibliotheken, um Code zu enthalten, der sich nicht viel ändert. Der Verknüpfungsschritt führt bei Bibliotheken schneller als bei Verzeichnissen von Objektdateien.
Allerdings können die Arbeitsorte (auch als Shops bezeichnet) andere Stilregeln haben, die befolgt werden müssen.
Es ist nicht notwendig, dass Ihre Header-Dateien und cpp-Dateien im selben Ordner liegen. Ich habe das schon oft gemacht. Sie können die Dateien in verschiedenen Ordnern speichern und eine andere Datei verwenden, um beide Dateien in der Datei abzurufen / einzuschließen, die Sie als Include verwenden. Besuchen Sie den folgenden Link, um ein besseres Verständnis dessen zu bekommen, was ich sage. Es zeigt Ihnen, wie Sie Ihre eigene Dateiorganisationsstruktur implementieren.
Tags und Links c++ architecture