Das folgende ist ziemlich typisch ...
third-party library
release
obj
debug
obj
include
src
sublib 1
sublib 2
mylibrary
release
obj
debug
obj
include
src
sublib 1
sublib 2
myapp
release
obj
debug
obj
subapp 1
subapp 2
mylittleapp
release
obj
debug
obj
Grundsätzlich Unterordner für Teilprojekte gemeinsam für größere Projekte, sondern vor allem ein bestimmtes Projekt hat Ordner für src enthalten usw. Ein Ordner für jeden Build-Konfiguration üblich, und halten Sie die Obj-Dateien und andere Zwischenprodukte in einem Unterordner davon ist 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 Ordner "src".
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. Normalerweise ist diese Unterteilung jedoch Teilprojekt wenn es überhaupt wert ist, getrennt zu werden. Wie Sie Teilprojekte aufteilen, 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 aufgabenspezifischer Logik behandelt werden.
Namespaces sind nicht die meistgenutzte Sprachfunktion, 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 einschließe.
Im Wesentlichen sind Namespaces 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 mit dem Namespace "std" ist es in Ordnung, einen Los von Zeug in einem Namespace zu setzen.
Wie Sie sagen, ist dies jedoch keine definitive Antwort - es gibt natürlich kleinere Variationen und ganz andere Ansätze.
Welche Art von Umgebung verwenden Sie? – ihtkwot
Wo man eine Programmausgabe setzt, ist eine ganz andere Sache und wahrscheinlich besser als eine andere Frage gefragt. –
@gf guter Punkt. redigiert es. – Stephano