it-swarm.com.de

Warum Kopfzeilen in ein separates Verzeichnis stellen?

Ich weiß, dass es in C/C++ - Projekten üblich ist, Headerdateien in einem Verzeichnis wie include und die Implementierung in einem separaten Verzeichnis wie src abzulegen. Ich habe mit verschiedenen Projektstrukturen gespielt und frage mich, ob es dafür objektive Gründe gibt oder ob es einfach Konvention ist.

16
Doug Moore

Konvention ist einer der Gründe - meistens interessiert Sie bei einer effektiven Abstraktion nur die Benutzeroberfläche, und Sie möchten es einfach haben, nur die Überschriften zu betrachten.

Dies ist jedoch nicht der einzige Grund. Wenn Ihr Projekt in Modulen organisiert ist, müssen Sie höchstwahrscheinlich einige Header in verschiedene Module aufnehmen und möchten, dass Ihr Include-Verzeichnis von anderen "Rausch" -Dateien befreit wird.

Wenn Sie beabsichtigen, Ihr Modul neu zu verteilen, möchten Sie wahrscheinlich die Implementierungsdetails ausblenden. Sie liefern also nur Header und Binärdateien - und die Verteilung von Headern aus einem einzigen Ordner, in dem sich nichts anderes befindet, ist einfacher.

Es gibt auch eine Alternative die ich eigentlich bevorzuge - öffentliche Header werden in einem separaten Ordner abgelegt (diese enthalten die Mindestschnittstelle - es sind keinerlei Implementierungsdetails sichtbar), und private Header und Implementierungsdateien sind separat (möglicherweise, aber nicht unbedingt). in separaten Ordnern).

25
Luchian Grigore

Ich ziehe es vor, sie in das Verzeichnis same zu stellen. Grund:

Die Schnittstellenspezifikationsdatei (en) und die Quelldatei (en), die diese Schnittstelle implementieren, gehören zum selben Teil des Projekts. Angenommen, Sie haben subsystemx. Wenn Sie dann subsystemx-Dateien in das Verzeichnis subsystemx einfügen, ist subsustemx in sich abgeschlossen.

Wenn es viele Include-Dateien gibt, können Sie subsystemx/include und subsystemx/source sicher tun, aber dann behaupte ich, wenn Sie die Definition von class Foo in foo.hpp und foo.cpp einfügen, möchten Sie auf jeden Fall beide sehen (oder haben zumindest die Möglichkeit dazu) leicht) zusammen in einer Verzeichnisliste. Suche nach allen Dateien mit Bezug zu foo

ls foo*

Suchen aller Implementierungsdateien:

ls *.cpp

Alle Deklarationsdateien finden:

ls *.hpp

Einfach und sauber.

7
user877329

Es hält Ihre Ordnerstruktur sauberer. Kopfzeilen und Quelldateien unterscheiden sich deutlich und werden für verschiedene Zwecke verwendet. Daher ist es sinnvoll, sie zu trennen. Aus dieser Sicht ist die Frage im Grunde die gleiche wie " Warum werden Quelldateien und Dokumentation in unterschiedlichen Ordnern abgelegt "? Der Computer ist sehr agnostisch in Bezug auf das, was Sie in Ordnern ablegen und was nicht. Ordner sind zum größten Teil nur eine nützliche Abstraktion, da wir Menschen Informationen analysieren, speichern und abrufen.

Es gibt auch die Tatsache, dass Header-Dateien nützlich bleiben auch nachdem Sie erstellt haben , dh wenn Sie eine Bibliothek erstellen und jemand diese Bibliothek verwenden möchte, benötigt er die Header-Dateien - nicht die Quelldateien - - so wird das Bündeln dieser Header-Dateien vereinfacht - das Aufnehmen des Materials in bin und des Materials in include und nicht das Durchsuchen von src - viel einfacher.

Neben der (fragwürdigen?) Nützlichkeit, um die Dinge in Ordnung zu halten, in anderen Projekten usw., gibt es einen sehr neutralen und objektiven Vorteil: die Kompilierungszeit.

Insbesondere in einem großen Projekt mit einer ganzen Reihe von Dateien, in Abhängigkeit von den Suchpfaden für die Header (.c/.cpp-Dateien verwenden #include "headername.h" statt #include "../../gfx/misc/something/headername.h" und der Compiler hat die richtigen Parameter übergeben, um dies schlucken zu können), reduzieren Sie dies drastisch Die Anzahl der Einträge, die vom Compiler auf der Suche nach dem richtigen Header gescannt werden müssen. Da die meisten Compiler für jede kompilierte Datei separat starten, müssen sie die Liste der Dateien im Include-Pfad einlesen und die richtigen Header für jede kompilierte Datei suchen. Wenn sich eine Reihe von .c-, .o- und anderen irrelevanten Dateien im Include-Pfad befinden, dauert das Auffinden der Includes unter ihnen proportional länger.

2
SF.

Kurz gesagt, ein paar Gründe:

  • Wartungsfähiger Code.
  • Code ist gut gestaltet und ordentlich.
  • Schnellere Kompilierzeit (manchmal für kleinere Änderungen).
  • Einfachere Trennung der Interfaces zur Dokumentation etc.
  • Zyklische Abhängigkeiten zur Kompilierzeit können vermieden werden.
  • Leicht zu überprüfen.

Werfen Sie einen Blick auf den Artikel Organisieren von Codedateien in C und C++ , der dies gut erklärt.

0
parasrish