Warum ein include/-Verzeichnis in C- und C++-Projekten erstellen?

Wenn ich an meinen persönlichen C- und C++-Projekten arbeite, setze ich normalerweise file.h und file.cpp im selben Verzeichnis und dann file.cpp verweisen kann file.h mit einer #include "file.h" Richtlinie.

Es ist jedoch üblich, Bibliotheken und andere Arten von Projekten (wie den Linux-Kernel und freeRTOS) zu finden, in denen alle vorhanden sind .h Dateien werden innerhalb einer abgelegt include/ Verzeichnis, während .cpp Dateien verbleiben in einem anderen Verzeichnis. Bei diesen Projekten .h Dateien sind ebenfalls enthalten #include "file.h" Anstatt von #include "include/file.h" wie ich gehofft hatte.

Zu all dem habe ich einige Fragen:

1. Was sind die Vorteile dieser Dateistrukturorganisation?
2. Warum sind .h Dateien drin include/ inbegriffen #include "file.h" Anstatt von #include "include/file.h"? Ich weiß, dass der eigentliche Trick in einigen Makefiles steckt, aber ist es wirklich besser, dies auf diese Weise zu tun, anstatt (im Code) klarzustellen, dass die Datei, die wir einschließen möchten, tatsächlich in der include/ Verzeichnis?

Der Hauptgrund dafür ist, dass kompilierte Bibliotheken Header benötigen, um vom späteren Benutzer verwendet werden zu können. Vereinbarungsgemäß ist der Inhalt der include Verzeichnis sind die Header, die für den öffentlichen Gebrauch verfügbar gemacht werden. Das Quellverzeichnis kann Header für den internen Gebrauch haben, aber das sind sie nicht soll mit der kompilierten Bibliothek verteilt werden.

Wenn Sie also die Bibliothek verwenden, verknüpfen Sie sie mit der Binärdatei und fügen die der Bibliothek hinzu include Verzeichnis zu den Headerpfaden Ihres Build-Systems. Wenn Sie Ihre kompilierte Bibliothek an einem zentralen Ort installieren, können Sie auf ähnliche Weise feststellen, welche Dateien an den zentralen Ort kopiert werden müssen (die kompilierten Binärdateien und die include Verzeichnis) und welche Dateien nicht (das Quellverzeichnis und so weiter).

Früher war das so <header> Style Includes waren vom impliziten Pfadtyp, d. h. auf dem zu finden includes Umgebungsvariablenpfad oder ein Build-Makro und die "header" Stileinbindungen hatten die explizite Form, wie-in, genau relativ zu der Quelldatei, in der sie enthalten war. Während einige Build-Toolketten diese Unterscheidung noch zulassen, verwenden sie häufig standardmäßig eine Konfiguration, die sie effektiv aufhebt.

Ihre Frage ist interessant, weil sie die Frage aufwirft, was wirklich besser ist, implizit oder explizit? Die implizite Form ist sicherlich einfacher, weil:

1. Praktische Gruppierungen zusammengehöriger Header in Verzeichnishierarchien.
2. Sie müssen nur ein paar Verzeichnisse in die Datei aufnehmen includes Pfad und müssen nicht jedes Detail in Bezug auf die genauen Speicherorte von Dateien kennen. Sie können Versionen von Bibliotheken und ihren zugehörigen Headern ändern, ohne den Code zu ändern.
3. TROCKEN.
4. Flexibel! Ihre Build-Umgebung muss nicht mit meiner übereinstimmen, aber wir können oft fast genau die gleichen Ergebnisse erzielen.

Explicit hingegen hat:

1. Wiederholbare Builds. Eine Neuordnung von Pfaden in einer includes Makro-/Umgebungsvariable, ändert keine resultierenden Header-Dateien, die während des Builds gefunden wurden.
2. Tragbare Konstruktionen. Verpacken Sie einfach alles von der Wurzel des Builds und versenden Sie es an einen anderen Entwickler.
3. Nähe von Informationen. Sie wissen genau, wo der Header mit ist #include "\X\Y\Z". In der impliziten Form müssen Sie möglicherweise mehrere Pfade durchsuchen und finden möglicherweise sogar mehrere Versionen derselben Datei. Woher wissen Sie, welche im Build verwendet wird?

Entwickler streiten seit vielen Jahrzehnten über diese beiden Ansätze, aber eine Hybridform der beiden gewinnt meistens aufgrund des Aufwands, der erforderlich ist, um Builds zu verwalten, die ausschließlich auf der expliziten Form basieren, und der offensichtlichen Schwierigkeit, sich mit Code vertraut zu machen rein impliziter Natur. Wir alle verstehen im Allgemeinen, dass unsere verschiedenen Toolketten bestimmte gemeinsame Bibliotheken und Header an bestimmten Orten ablegen, sodass sie von Benutzern und Projekten gemeinsam genutzt werden können. Daher erwarten wir, Standard-C/C++-Header an einem Ort zu finden, aber das tun wir zunächst nicht wissen nichts über die spezifische Struktur eines beliebigen Projekts, da es an einer lokal gut dokumentierten Konvention mangelt, also erwarten wir, dass der Code in diesen Projekten explizit in Bezug auf die nicht standardmäßigen Bits ist, die für sie einzigartig sind, und implizit in Bezug auf die Standardbits.

Es ist eine gute Praxis, immer die zu verwenden <header> Form des Include für alle Standard-Header und andere Bibliotheken, die nicht projektspezifisch sind und die verwendet werden sollen "header" Formular für alles andere. Sollten Sie in Ihrem Projekt ein Include-Verzeichnis für Ihre lokalen Include-Dateien haben? Das hängt bis zu einem gewissen Grad davon ab, ob diese Header als Schnittstellen zu Ihren Bibliotheken geliefert oder lediglich von Ihrem Code verwendet werden, und auch von Ihren Einstellungen. Wie groß und komplex ist Ihr Projekt? Wenn Sie eine Mischung aus internen und externen Schnittstellen oder vielen verschiedenen Komponenten haben, möchten Sie die Dinge vielleicht in separaten Verzeichnissen gruppieren.

Denken Sie daran, dass die Verzeichnisstruktur, in die Ihr fertiges Produkt entpackt wird, nicht so aussehen muss wie die Verzeichnisstruktur, unter der Sie dieses Produkt entwickeln und bauen. Wenn Sie nur wenige .c/.cpp-Dateien und Header haben, ist es in Ordnung, sie zu platzieren Sie alle in einem Verzeichnis, aber irgendwann werden Sie an etwas nicht Trivialem arbeiten und müssen die Konsequenzen Ihrer Build-Umgebungsentscheidungen durchdenken und es hoffentlich dokumentieren, damit andere es verstehen können.

1 . .hpp und .cpp müssen nicht unbedingt eine 1-zu-1-Beziehung haben, es kann mehrere .cpp-Dateien geben, die dieselbe .hpp-Datei verwenden, je nach unterschiedlichen Bedingungen (z. B.: unterschiedliche Umgebungen), zum Beispiel: eine Bibliothek für mehrere Plattformen, stellen Sie sich vor, es gibt eine Klasse um die Version der App zu erhalten, und der Header sieht so aus:

Dienstprogramme.h

#include <string.h>
class Utilities{
    static std::string getAppVersion();
}

main.cpp

#include Utilities.h
int main(){
    std::cout << Utilities::getAppVersion() << std::ends;
    return 0;
}

es kann eine .cpp für jede Plattform geben, und die .cpp kann an verschiedenen Orten platziert werden, so dass sie leicht von der entsprechenden Plattform ausgewählt werden können, z. B.:

.cpp für iOS (Pfad:DemoProject/ios/Utilities.cpp):

#include "Utilities.h"
std::string Utilities::getAppVersion(){
    //some objective C code
}

.cpp für Android (Pfad:DemoProject/android/Utilities.cpp):

#include "Utilities.h"
std::string Utilities::getAppVersion(){
    //some jni code
}

und natürlich würden 2 .cpp normalerweise nicht gleichzeitig verwendet werden.

2.

#include "file.h" 

Anstatt von

#include "include/file.h" 

ermöglicht es Ihnen, den Quellcode unverändert zu lassen, wenn Ihre Header nicht mehr im “include”-Ordner abgelegt werden.