*.h oder *.hpp für Ihre Klassendefinitionen

Question

Ich habe immer eine *.h Datei für meine Klassendefinitionen, aber nachdem ich den Code einiger Boost-Bibliotheken gelesen hatte, stellte ich fest, dass sie alle *.hpp . Ich hatte schon immer eine Abneigung gegen diese Dateierweiterung, vor allem, weil ich sie nicht gewohnt bin.

Was sind die Vor- und Nachteile der Verwendung von *.hpp en *.h ?

Answer 1

C++ ("C Plus Plus") ist als .cpp sinnvoll

Header-Dateien mit der Erweiterung .hpp haben nicht den gleichen logischen Ablauf.

Answer 2

Bjarne Stroustrup und Herb Sutter haben eine Erklärung zu dieser Frage in ihren C++ Core-Leitlinien, die auf zu finden sind: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#S-source die sich auch auf die neuesten Änderungen in der Standarderweiterung beziehen (C++11, C++14 usw.)

SF.1: Verwenden Sie die Endung .cpp für Codedateien und .h für Schnittstellendateien, wenn Ihr Y Projekt nicht bereits einer anderen Konvention folgt Grund

Das ist eine seit langem bestehende Konvention. Aber Konsistenz ist wichtiger, also wenn Ihr Projekt etwas anderes verwendet, folgen Sie diesem. Hinweis

Diese Konvention spiegelt ein gängiges Verwendungsmuster wider: Header werden häufiger gemeinsam mit C geteilt, um sowohl als C++ als auch als C kompiliert zu werden, was typischerweise .h verwendet, und es ist ist es einfacher, alle Header .h zu nennen, als verschiedene Erweiterungen für nur für die Header zu haben, die gemeinsam mit C verwendet werden sollen. Andererseits, Implementierungsdateien nur selten mit C geteilt und sollten daher typischerweise von .c-Dateien unterschieden werden, daher ist es normalerweise am besten, alle C++ Implementierungsdateien einen anderen Namen zu geben (z.B. .cpp).

Die spezifischen Namen .h und .cpp sind nicht erforderlich (nur empfohlen als Standard) und andere Namen sind weit verbreitet. Beispiele sind .hh, .C, und .cxx. Verwenden Sie solche Namen gleichwertig. In diesem Dokument beziehen wir uns auf .h und .cpp > als Kurzform für Header- und Implementierungsdateien, auch wenn die tatsächliche Erweiterung unterschiedlich sein kann.

Ihre IDE (falls Sie eine verwenden) hat möglicherweise eine starke Meinung zu "suffices".

Ich bin kein großer Fan dieser Konvention, denn wenn Sie eine beliebte Bibliothek wie boost verwenden, ist Ihre Konsistenz bereits gebrochen und Sie sollten besser .hpp verwenden.

Answer 3

Codegear C++Builder verwendet .hpp für Header-Dateien, die automatisch aus Delphi-Quelldateien generiert werden, und .h-Dateien für Ihre "eigenen" Header-Dateien.

Wenn ich also eine C++-Header-Datei schreibe, verwende ich immer .h.

Answer 4

In einem meiner Jobs in den frühen 90er Jahren haben wir .cc und .hh für Quell- bzw. Header-Dateien verwendet. Ich bevorzuge es immer noch gegenüber allen Alternativen, wahrscheinlich weil es am einfachsten zu tippen ist.

Answer 5

Für Werkzeuge und Menschen ist es leicht zu unterscheiden etwas . Das war's.

Bei herkömmlicher Verwendung (durch Boosten usw.), .hpp ist speziell C++-Header. Auf der anderen Seite, .h ist für Kopfzeilen, die nicht nur aus C++ bestehen (hauptsächlich C). Die genaue Erkennung der Sprache des Inhalts ist im Allgemeinen schwierig, da es viele nicht-triviale Fälle gibt, so dass dieser Unterschied oft die Erstellung eines gebrauchsfertigen Tools erleichtert. Für Menschen, die die Konvention einmal verstanden haben, ist sie auch leicht zu merken und zu verwenden.

Ich möchte jedoch darauf hinweisen, dass die Konvention selbst nicht immer wie erwartet funktioniert.

• Sie wird nicht durch die Spezifikation von Sprachen erzwungen weder C noch C++. Es gibt viele Projekte, die sich nicht an diese Konvention halten. Sobald Sie sie zusammenführen (mischen) müssen, kann das mühsam sein.
• .hpp selbst ist nicht die einzige Wahl. Warum nicht .hh o .hxx ? (Obwohl man normalerweise mindestens eine konventionelle Regel für Dateinamen und Pfade braucht).

Ich persönlich benutze beides .h y .hpp in meinen C++-Projekten. Ich halte mich nicht an die obige Konvention, weil:

• Die von den einzelnen Projektteilen verwendeten Sprachen sind ausdrücklich dokumentiert. Keine Möglichkeit, C und C++ im selben Modul (Verzeichnis) zu mischen. Jede Bibliothek von Drittanbietern muss diese Regel einhalten.
• Die konformen Sprachspezifikationen und die zulässigen Sprachdialekte, die von den Projekten verwendet werden, sind ebenfalls dokumentiert. (In der Tat dokumentiere ich sogar die Quelle der verwendeten Standardfunktionen und Fehlerbehebungen (für den Sprachstandard) .) Dies ist etwas wichtiger als die Unterscheidung der verwendeten Sprachen, da dies zu fehleranfällig ist und die Kosten für den Test (z.B. Compilerkompatibilität) erheblich sein können (kompliziert und zeitaufwendig), insbesondere bei einem Projekt, das bereits in fast rein C++. Dateinamen sind zu schwach, um dies zu handhaben.
• Selbst für denselben C++-Dialekt kann es wichtigere Eigenschaften geben, die für den Unterschied geeignet sind. Siehe zum Beispiel die folgende Konvention.
• Dateinamen sind im Wesentlichen Teile von fragilen Metadaten. Die Verletzung von Konventionen ist nicht so leicht zu erkennen. Um einen stabilen Umgang mit dem Inhalt zu gewährleisten, sollte ein Werkzeug schließlich nicht nur auf Namen angewiesen sein. Der Unterschied zwischen Erweiterungen ist nur ein Hinweis. Von Werkzeugen, die sie verwenden, sollte auch nicht erwartet werden, dass sie sich immer gleich verhalten, z. B. die Spracherkennung von .h Dateien auf github.com. (Es kann etwas in den Kommentaren stehen wie shebang für diese Quelldateien, um bessere Metadaten zu erhalten, aber sie sind auch nicht so konventionell wie Dateinamen, also im Allgemeinen auch nicht zuverlässig).

Ich verwende normalerweise .hpp auf C++-Kopfzeilen und die Kopfzeilen sollten in einem Verzeichnis verwendet (gepflegt) werden. Nur für den Kopf z.B. in Form von Vorlagenbibliotheken. Für andere Kopfzeilen in .h gibt es entweder eine entsprechende .cpp Datei als Implementierung, oder es ist ein Nicht-C++-Header. Letzteres lässt sich anhand des Inhalts des Headers leicht von Menschen unterscheiden (oder von Tools mit explizit eingebetteten Metadaten, falls erforderlich).