C ++ Projekt Quellcode-Layout

Question

Eines der beliebtesten Wege Projektverzeichnis zu organisieren, ist mehr oder weniger wie folgt aus:

MyLib
     +--mylib_class_a.h
        mylib_class_a.cpp
        mylib_library_private_helpers.h
        mylib_library_private_helpers.cpp

MyApp
     +--other_class.h
        other_class.cpp
        app.cpp

app.cpp:

#include "other_class.h"
#include <mylib_class_a.h> // using library MyLib

Alle .h und .cpp Dateien für die gleiche Bibliothek sind im selben Verzeichnis. Um Namenskollision zu vermeiden, werden Präfix Dateinamen häufig mit Firmennamen und / oder Bibliotheksnamen. MyLib wird in MeineAnw Header-Suchpfad sein, etc. Ich bin kein Fan von prefixing Dateinamen, aber Ich mag die Idee des Blicks auf dem #include und genau wissen, wo die Header-Datei gehört. Ich weiß nicht, diesen Ansatz hassen Dateien zu organisieren, aber ich denke, es sollte ein besserer Weg geben.

Da ich ein neues Projekt starten, möchte ich einige Verzeichnis Organisation Ideen werben. Ich mag zur Zeit diese Verzeichnisstruktur:

ProjA
    +--include
             +--ProjA
                    +--mylib
                           +--class_a.h
                    +--app
                           +--other_class.h
    +--src
         +--mylib
                +--class_a.cpp
                   library_private_helpers.h
                   library_private_helpers.cpp
         +--app
              +--other_class.cpp
                 app.cpp
                 util.h

app.cpp:

#include "util.h" // private util.h file
#include <ProjA/app/other_class.h> // public header file
#include <ProjA/mylib/class_a.h> // using class_a.h of mylib
#include <other3rdptylib/class_a.h> // class_a.h of other3rdptylib, no name collision
#include <class_a.h> // not ProjA/mylib/class_a.h
#include <ProjA/mylib/library_private_helpers.h> // error can't find .h 

.cpp Dateien und private (nur sichtbar für sofortige Bibliothek) .h Dateien werden unter dem src-Verzeichnis gespeichert (src wird manchmal lib genannt). Öffentliche Header-Dateien werden in ein Projekt / lib Verzeichnisstruktur organisiert und über <ProjectName/LibraryName/headerName.h> enthalten. Die Dateinamen werden nicht mit irgendetwas vorangestellt. Wenn ich jemals wieder zu verpacken MyLib benötigt, um von anderen Teams verwendet werden, konnte ich einfach mein Make-Datei ändern Sie die entsprechenden Binärdateien und das Ganze zu kopieren include / proja Verzeichnis.

Sobald die Dateien in die Quellcodeverwaltung überprüft werden, und die Menschen beginnen an ihnen arbeiten wird es schwer sein Verzeichnisstruktur zu ändern. Es ist besser, es richtig zu machen bei der get-go.

Jeder mit Erfahrung Quellcode wie diese zu organisieren? Alles, was Sie nicht über es? Wenn Sie einen besseren Weg, es zu tun, würde ich sehr gerne davon hören.

Answer 1

Nun, es hängt alles davon ab, wie groß diese Projekte sind. Wenn Sie nur ein paar Dateien haben, dann haut sie alle in einem Ordner.

Zu viele Ordner, wenn Sie nicht viele Dateien bekommen haben, ist übertrieben meiner Meinung nach zu verwalten. Es nervt graben in und aus Ordnern, wenn Sie haben nur ein paar Dateien in ihnen.

Auch hängt es davon ab, die dieses Zeug mit. Wenn Sie eine Bibliothek gerade schreiben und sein Gehen von anderen Programmierern verwendet wird, dann ist es gut, den Header sie in einen Ordner enthalten verwenden mag, zu organisieren. Wenn Sie eine Reihe von Bibliotheken sind das Erstellen und Veröffentlichen sie alle, dann könnte Ihre Struktur arbeiten. Aber, wenn sie unabhängige Bibliotheken sind, und die Entwicklung ist alles in allem nicht getan und sie bekommen versioniert und zu verschiedenen Zeiten veröffentlicht, dann würden Sie besser dran kleben sein mit alle Dateien für ein Projekt mit lokalisierbar innerhalb eines Ordners.

In der Tat, würde ich sagen, alles halten in einem Ordner, bis Sie zu einem Punkt, wo man seine unmanagable finden, dann reorganisiert in eine kluge Regelung von der Quelle bis in Ordner sortieren, wie Sie getan haben. Sie werden wahrscheinlich wissen, wie es von den Problemen organisiert werden muss man den Weg laufen.

KISS ist in der Regel immer die Lösung in der Programmierung -> alles so einfach wie möglich halten

.

Answer 2

Warum nicht so etwas wie die ersten tun, verwenden Sie nur das Verzeichnis, das MyLib als Teil der Richtlinie enthalten wohnt, die die dumme Vorfixierung reduziert:

#include <MyLib/ClassA.h>

Das sagen Sie, wo sie aus sind. Was die zweite Wahl, erhalte ich persönlich wirklich verärgert, wenn ich eine Kopf- oder Quelldatei geöffnet haben, und um durch die Verzeichnisstruktur navigieren müssen, um die andere, und öffnen Sie es zu finden. Mit Ihrem zweiten Beispiel, wenn Sie offen src/mylib/class_a.cpp hatte, und wollte den Header, in vielen Editoren bearbeiten würden Sie wieder zwei Ebenen gehen, dann in include/ProjA vor den Header zu finden. Und wie sollen wir wissen, dass der Header im ProjA Unterverzeichnis ist ohne einig anderen externen Hinweis? Außerdem ist es zu einfach für eine Datei oder die andere in einen anderen Ort gebracht werden, dass „besser“ darstellt, wie es verwendet wird, ohne die alternative Datei verschoben werden. Es gibt nur Kopfschmerzen mich, wenn ich es in meinem Job begegnen (und wir haben einige Teile unserer Code-Basis haben, wo die Menschen jedes potentielle Problem habe ich gerade erwähnt habe).

Answer 3

Ich habe beiden Methoden ausprobiert. Ich persönlich mag die erste besser. Ich verstehe den Drang, alles in spezifischere Verzeichnissen zu setzen, aber es verursacht eine Menge über Komplikation.

ich in der Regel diese Regel verwenden: Anwendungen und in-house-Bibliotheken verwenden Sie die erste Methode. Öffentliche Open-Source-Bibliotheken verwenden die zweite Methode. Wenn Sie den Code veröffentlichen, es hilft viel, wenn die Include-Dateien in einem separaten Verzeichnis sind.