Ich habe immer eine *.hDatei für meine Klassendefinitionen verwendet, aber nachdem ich einen Boost-Bibliothekscode gelesen hatte, stellte ich fest, dass sie alle verwenden *.hpp. Ich hatte immer eine Abneigung gegen diese Dateierweiterung, ich denke hauptsächlich, weil ich nicht daran gewöhnt bin.

Was sind die Vor- und Nachteile von *.hppOver *.h?

Hier sind einige Gründe für die unterschiedliche Benennung von C- und C ++ - Headern:

• Bei der automatischen Code-Formatierung gelten möglicherweise andere Richtlinien für die Formatierung von C- und C ++ - Code. Wenn die Überschriften durch eine Erweiterung getrennt sind, können Sie Ihren Editor so einstellen, dass die entsprechende Formatierung automatisch angewendet wird
• Ich war an Projekten beteiligt, in denen Bibliotheken in C geschrieben wurden und dann Wrapper in C ++ implementiert wurden. Da die Header normalerweise ähnliche Namen hatten, dh Feature.h vs Feature.hpp, waren sie leicht zu unterscheiden.
• Inklusive, möglicherweise verfügt Ihr Projekt über geeignetere Versionen, die in C ++ geschrieben sind, aber Sie verwenden die C-Version (siehe oben). Wenn Header nach der Sprache benannt sind, in der sie implementiert sind, können Sie leicht alle C-Header erkennen und nach C ++ - Versionen suchen.

Denken Sie daran, dass C nicht C ++ ist und das Mischen und Anpassen sehr gefährlich sein kann, wenn Sie nicht wissen, was Sie tun. Wenn Sie Ihre Quellen richtig benennen, können Sie die Sprachen besser unterscheiden.

Ich verwende .hpp, weil ich möchte, dass der Benutzer unterscheidet, welche Header C ++ - Header und welche Header C-Header sind.

Dies kann wichtig sein, wenn Ihr Projekt sowohl C- als auch C ++ - Module verwendet: Wie jemand anderes vor mir erklärt hat, sollten Sie dies sehr sorgfältig tun und es beginnt mit dem "Vertrag", den Sie über die Erweiterung anbieten

.hpp: C ++ - Header

(Oder .hxx oder .hh oder was auch immer)

Dieser Header ist nur für C ++.

Wenn Sie sich in einem C-Modul befinden, versuchen Sie nicht einmal, es einzuschließen. Sie werden es nicht mögen, weil keine Anstrengungen unternommen werden, um es C-freundlich zu machen (zu viel würde verloren gehen, wie Funktionsüberladung, Namespaces usw. usw.).

.h: C / C ++ - kompatible oder reine C-Header

Dieser Header kann direkt oder indirekt sowohl von einer C-Quelle als auch von einer C ++ - Quelle enthalten sein.

Es kann direkt aufgenommen werden und wird durch das __cplusplusMakro geschützt :

• Dies bedeutet, dass aus C ++ - Sicht der C-kompatible Code definiert wird als extern "C".
• Aus C-Sicht ist der gesamte C-Code deutlich sichtbar, der C ++ - Code wird jedoch ausgeblendet (da er in einem C-Compiler nicht kompiliert wird).

Zum Beispiel:

#ifndef MY_HEADER_H
#define MY_HEADER_H

   #ifdef __cplusplus
      extern "C"
      {
   #endif

   void myCFunction() ;

   #ifdef __cplusplus
      } // extern "C"
   #endif

#endif // MY_HEADER_H

Oder es könnte indirekt durch den entsprechenden .hpp-Header eingefügt werden, der der extern "C"Deklaration beigefügt ist .

Zum Beispiel:

#ifndef MY_HEADER_HPP
#define MY_HEADER_HPP

extern "C"
{
#include "my_header.h"
}

#endif // MY_HEADER_HPP

und:

#ifndef MY_HEADER_H
#define MY_HEADER_H

void myCFunction() ;

#endif // MY_HEADER_H

Ich habe den .hppHeader immer als eine Art Portmanteau von .hund .cppDateien angesehen ... als Header, der auch Implementierungsdetails enthält.

Wenn ich .hppeine Erweiterung gesehen (und verwendet) habe , gibt es normalerweise keine entsprechende .cppDatei. Wie andere gesagt haben, ist dies keine feste Regel, nur wie ich dazu neige, .hppDateien zu verwenden .

Es spielt keine Rolle, welche Erweiterung Sie verwenden. Beides ist in Ordnung.

Ich benutze *.hfür C und *.hppfür C ++.

EDIT [Vorschlag von Dan Nissenbaum hinzugefügt]:

Nach einer Konvention werden .hpp-Dateien verwendet, wenn die Prototypen im Header selbst definiert sind. Solche Definitionen in Headern sind bei Vorlagen nützlich, da der Compiler den Code für jeden Typ nur bei der Instanziierung von Vorlagen generiert. Wenn sie nicht in Header-Dateien definiert sind, werden ihre Definitionen zum Zeitpunkt der Verknüpfung nicht von anderen Kompilierungseinheiten aufgelöst. Wenn es sich bei Ihrem Projekt um ein C ++ - Projekt handelt, bei dem Vorlagen häufig verwendet werden, ist diese Konvention hilfreich.

Bestimmte Vorlagenbibliotheken, die dieser Konvention entsprechen, stellen Header mit .hpp-Erweiterungen bereit, um anzuzeigen, dass sie keine entsprechenden .cpp-Dateien haben.

Eine andere Konvention besteht darin, .h für C-Header und .hpp für C ++ zu verwenden. Ein gutes Beispiel wäre die Boost-Bibliothek.

Zitat aus Boost FAQ,

Dateierweiterungen kommunizieren den "Typ" der Datei sowohl an Menschen als auch an Computerprogramme. Die Erweiterung '.h' wird für C-Header-Dateien verwendet und kommuniziert daher das Falsche über C ++ - Header-Dateien. Wenn Sie keine Erweiterung verwenden, wird nichts kommuniziert und die Überprüfung des Dateiinhalts erzwungen, um den Typ zu bestimmen. Die Verwendung von '.hpp' identifiziert es eindeutig als C ++ - Headerdatei und funktioniert in der Praxis gut. (Rainer Deyke)

Ich habe vor kurzem begonnen, *.hppfür C ++ - Header zu verwenden.

Der Grund dafür ist, dass ich Emacs als primären Editor verwende und es beim Laden einer *.hDatei automatisch in den C-Modus und beim Laden einer Datei in den C ++ - Modus wechselt *.hpp.

Abgesehen davon , dass Tatsache , sehe ich keine guten Gründe für die Wahl *.hüber *.hppoder umgekehrt.

Ich beantworte dies als Erinnerung, um auf meine Kommentare zu "user1949346" zu verweisen, die auf dasselbe OP antworten.

So viele haben bereits geantwortet: So oder so ist es in Ordnung. Gefolgt von Hervorhebungen ihrer eigenen Eindrücke.

Einleitend, wie auch in den zuvor genannten Kommentaren angegeben, ist meine Meinung, dass C++Header-Erweiterungen vorgeschlagen werden, .hwenn es tatsächlich keinen Grund dagegen gibt.

Da die ISO / IEC-Dokumente diese Notation von Header-Dateien verwenden und .hppin ihren Sprachdokumentationen über überhaupt keine Zeichenfolgenübereinstimmung mit auftritt C++.

Aber ich strebe jetzt einen akzeptablen Grund an, WARUM so oder so in Ordnung ist und insbesondere, warum es nicht Gegenstand der Sprache selbst ist.

Auf geht's.

Die C++Dokumentation (ich beziehe mich tatsächlich auf die Version N3690) definiert, dass ein Header der folgenden Syntax entsprechen muss:

2.9 Headernamen

header-name:
    < h-char-sequence >
    " q-char-sequence "
h-char-sequence:
    h-char
    h-char-sequence h-char
h-char:
    any member of the source character set except new-line and >
q-char-sequence:
    q-char
    q-char-sequence q-char
q-char:
    any member of the source character set except new-line and "

Wie wir aus diesem Teil extrahieren können, kann der Name der Header-Datei auch alles sein, was im Quellcode gültig ist. Außer '\n'Zeichen zu enthalten und je nachdem, ob es von eingeschlossen werden <>soll, darf es kein enthalten >. Oder umgekehrt, wenn es durch ""-include eingeschlossen ist, darf es kein a enthalten ".

Mit anderen Worten: Wenn Sie eine Umgebung hatten, die Dateinamen wie unterstützt prettyStupidIdea.>, ein Include wie:

#include "prettyStupidIdea.>"

wäre gültig, aber:

#include <prettyStupidIdea.>>

wäre ungültig. Umgekehrt das Gleiche.

Und selbst

#include <<.<>

wäre ein gültiger inklusive Header-Dateiname.

Sogar das würde passen C++, es wäre eine ziemlich dumme Idee, tho.

Und deshalb .hppgilt auch.

Aber es ist kein Ergebnis der Komitees, die Entscheidungen für die Sprache entwerfen!

So etwa zur Nutzung der Diskussion .hppist so , wie es zu tun .cc, .mmoder was auch immer , was ich in anderen Beiträgen zu diesem Thema lesen.

Ich habe ich keine Ahnung , zugeben, wo .hppherkommt ¹ , aber ich würde ein Erfinder einiger Parsing - Tool, IDE oder etwas anderes mit betroffenen Wette C++kam auf diese Idee , einige interne Prozesse zu optimieren oder einfach nur unbedingt für sie einige (wahrscheinlich sogar erfinden ) neue Namenskonventionen.

Aber es ist nicht Teil der Sprache.

Und wann immer man sich entscheidet, es so zu benutzen. Möge es sein, weil er es am meisten mag oder weil einige Anwendungen des Workflows es erfordern, es ist nie ² eine Anforderung der Sprache. Wer also sagt "das pp ist, weil es mit C ++ verwendet wird", ist einfach falsch in Bezug auf die Sprachdefinition.

C ++ erlaubt alles, was den vorherigen Absatz respektiert. Und wenn es etwas gibt, das das Komitee verwenden möchte, dann verwendet es es, .hda dies die Erweiterung ist, die in allen Beispielen des ISO-Dokuments verklagt wird.

Fazit:

Solange Sie keine Notwendigkeit sehen / fühlen, .hOver .hppoder umgekehrt zu verwenden, sollten Sie sich nicht darum kümmern. Weil beide einen gültigen Headernamen gleicher Qualität in Bezug auf den Standard bilden würden. Und daher ist alles, was Sie verwenden müssen .hoder .hppeine zusätzliche Einschränkung des Standards darstellt, die sogar anderen zusätzlichen Einschränkungen widersprechen könnte, die nicht miteinander übereinstimmen. Da OP jedoch keine zusätzlichen Spracheinschränkungen erwähnt, ist dies die einzig richtige und akzeptable Antwort auf die Frage

" * .h oder * .hpp für Ihre Klassendefinitionen " lautet:

Beide sind gleichermaßen korrekt und anwendbar, solange keine externen Einschränkungen vorliegen.

¹ _{Soweit ich weiß, ist es anscheinend das Boost-Framework, das diese .hppErweiterung entwickelt hat.}

² _{Natürlich kann ich nicht sagen, was einige zukünftige Versionen mit sich bringen werden!}

Ich bevorzuge .hpp für C ++, um sowohl den Editoren als auch anderen Programmierern klar zu machen, dass es sich eher um einen C ++ - Header als um eine C-Header-Datei handelt.

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

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

Sie können Ihre Includes nach Belieben aufrufen.

Sie müssen nur den vollständigen Namen im angeben #include.

Ich schlage vor, wenn Sie mit C arbeiten .hund wann mit C ++ zu verwenden .hpp.

Es ist am Ende nur eine Konvention.

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 ++ - Headerdatei schreibe, verwende ich immer .h.

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

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

SF.1: Verwenden Sie ein .cpp-Suffix für Codedateien und .h für Schnittstellendateien, wenn Ihr Y-Projekt nicht bereits einem anderen Konventionsgrund folgt

Es ist eine langjährige Konvention. Konsistenz ist jedoch wichtiger. Wenn Ihr Projekt also etwas anderes verwendet, befolgen Sie diese Anweisungen. Hinweis

Diese Konvention spiegelt ein allgemeines Verwendungsmuster wider: Header werden häufiger mit C geteilt, um sowohl C ++ als auch C zu kompilieren, wobei normalerweise .h verwendet wird, und es ist einfacher, alle Header .h zu benennen, anstatt nur für die beabsichtigten Header unterschiedliche Erweiterungen zu haben Auf der anderen Seite werden Implementierungsdateien nur selten mit C geteilt und sollten daher normalerweise von .c-Dateien unterschieden werden. Daher ist es normalerweise am besten, alle C ++ - Implementierungsdateien mit einem anderen Namen zu versehen (z. B. .cpp).

Die spezifischen Namen .h und .cpp sind nicht erforderlich (nur als Standard empfohlen) und andere Namen sind weit verbreitet. Beispiele sind .hh, .C und .cxx. Verwenden Sie solche Namen gleichwertig. In diesem Dokument wird .h und .cpp> als Abkürzung für Header- und Implementierungsdateien bezeichnet, auch wenn die tatsächliche Erweiterung möglicherweise unterschiedlich ist.

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.

Wie viele hier bereits erwähnt haben, bevorzuge ich die Verwendung von .hpp auch für reine Header-Bibliotheken, die Vorlagenklassen / -funktionen verwenden. Ich bevorzuge die Verwendung von .h für Header-Dateien, die von .cpp-Quelldateien oder gemeinsam genutzten oder statischen Bibliotheken begleitet werden.

Die meisten Bibliotheken, die ich entwickle, sind vorlagenbasiert und müssen daher nur Header sein. Beim Schreiben von Anwendungen neige ich jedoch dazu, die Deklaration von der Implementierung zu trennen und am Ende .h- und .cpp-Dateien zu erhalten

Zum Glück ist es einfach.

Sie sollten die Erweiterung .hpp verwenden, wenn Sie mit C ++ arbeiten, und Sie sollten .h für C verwenden oder C und C ++ mischen.

Ich verwende .h, weil Microsoft dies verwendet und den Codegenerator erstellt. Keine Notwendigkeit, gegen den Strich zu gehen.

In "The C ++ Programming Language, Dritte Ausgabe von Bjarne Stroustrup", dem C ++ - Buch Nr. 1, das man unbedingt lesen muss, verwendet er * .h. Daher gehe ich davon aus, dass die beste Vorgehensweise darin besteht, * .h zu verwenden.

* .Hpp ist aber auch in Ordnung!

Werkzeuge und Menschen können leicht etwas unterscheiden . Das ist es.

Bei der herkömmlichen Verwendung (durch Boost usw.) .hpphandelt es sich speziell um C ++ - Header. Auf der anderen Seite .hist für Nicht-C ++ - nur Header (hauptsächlich C). Die Sprache des Inhalts genau zu erkennen, ist im Allgemeinen schwierig, da es viele nicht triviale Fälle gibt. Dieser Unterschied macht es daher oft einfach, ein gebrauchsfertiges Tool zu schreiben. Für Menschen ist es nach Erhalt der Konvention auch leicht zu merken und leicht zu bedienen.

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

• Es wird nicht durch die Angabe von Sprachen erzwungen , weder C noch C ++. Es gibt viele Projekte, die nicht der Konvention folgen. Sobald Sie sie zusammenführen (mischen) müssen, kann dies problematisch sein.
• .hppselbst ist nicht die einzige Wahl. Warum nicht .hhoder .hxx? (Trotzdem benötigen Sie normalerweise mindestens eine herkömmliche Regel für Dateinamen und Pfade.)

Ich persönlich benutze beide .hund .hppin meinen C ++ - Projekten. Ich folge der obigen Konvention nicht, weil:

• Die von jedem Teil der Projekte verwendeten Sprachen werden explizit dokumentiert. Keine Möglichkeit, C und C ++ im selben Modul (Verzeichnis) zu mischen. Jede Bibliothek eines Drittanbieters muss dieser Regel entsprechen.
• Die von den Projekten verwendeten konformen Sprachspezifikationen und zulässigen Sprachdialekte werden ebenfalls dokumentiert. (Tatsächlich dokumentiere ich sogar die Quelle der verwendeten Standardfunktionen und Fehlerbehebungen (im Sprachstandard) .) Dies ist etwas wichtiger als die Unterscheidung der verwendeten Sprachen, da sie zu fehleranfällig sind und die Testkosten (z Compilerkompatibilität) kann erheblich sein (kompliziert und zeitaufwändig), insbesondere in einem Projekt, das sich bereits in fast reinem C ++ befindet. Dateinamen sind zu schwach, um damit umzugehen.
• Selbst für denselben C ++ - Dialekt gibt es möglicherweise wichtigere Eigenschaften, die für den Unterschied geeignet sind. Siehe zum Beispiel die Konvention unten.
• Dateinamen sind im Wesentlichen Teile fragiler Metadaten. Der Verstoß gegen die Konvention ist nicht so leicht zu erkennen. Um einen stabilen Umgang mit dem Inhalt zu gewährleisten, sollte ein Tool letztendlich nicht nur von Namen abhängen. Der Unterschied zwischen Erweiterungen ist nur ein Hinweis. Es ist auch nicht zu erwarten, dass sich Tools, die es verwenden, immer gleich verhalten, z. B. die Spracherkennung von .hDateien auf github.com. (Es mag etwas in Kommentaren wie shebang geben, dass diese Quelldateien bessere Metadaten sind, aber es ist sogar nicht konventionell wie Dateinamen, also auch im Allgemeinen nicht zuverlässig.)

Normalerweise verwende ich .hppauf C ++ Header und die Header sollten (gehalten) in einem verwendet werden Kopf nur Art und Weise, zB als Template - Bibliotheken. Für andere Header in .hgibt es entweder eine entsprechende .cppDatei als Implementierung oder einen Nicht-C ++ - Header. Letzteres ist trivial, um durch den Inhalt des Headers von Menschen (oder bei Bedarf von Tools mit explizit eingebetteten Metadaten) zu unterscheiden.

Die Erweiterung der Quelldatei kann für Ihr Build-System von Bedeutung sein. Beispielsweise haben Sie möglicherweise eine Regel in Ihrem Makefile für .cppoder in Ihren .cDateien, oder Ihr Compiler (z. B. Microsoft cl.exe) kompiliert die Datei je nach Erweiterung möglicherweise als C oder C ++.

Da Sie der #includeDirektive den gesamten Dateinamen angeben müssen, ist die Header-Dateierweiterung irrelevant. Sie können eine .cDatei in eine andere Quelldatei aufnehmen, wenn Sie möchten, da es sich nur um eine Textaufnahme handelt. Ihr Compiler hat möglicherweise die Option, die vorverarbeitete Ausgabe /Pzu sichern, um dies zu verdeutlichen (Microsoft: Vorverarbeitung in Datei, /EVorverarbeitung in stdout, /EPWeglassen von #lineAnweisungen, /CBeibehalten von Kommentaren)

Sie können sich .hppfür Dateien entscheiden, die nur für die C ++ - Umgebung relevant sind, dh Funktionen verwenden, die in C nicht kompiliert werden können.

Eine bestimmte Erweiterung hat keinen Vorteil, außer dass diese möglicherweise eine andere Bedeutung für Sie, den Compiler und / oder Ihre Tools hat. header.hist ein gültiger Header. header.hppist ein gültiger Header. header.hhist ein gültiger Header. header.hxist ein gültiger Header. h.headerist ein gültiger Header. this.is.not.a.valid.headerist ein gültiger Header in Ablehnung. ihjkflajfajfklafist ein gültiger Header. Solange der Name vom Compiler ordnungsgemäß analysiert werden kann und das Dateisystem ihn unterstützt, ist er ein gültiger Header, und der einzige Vorteil seiner Erweiterung besteht darin, was man in ihn einliest.

Abgesehen davon ist es sehr nützlich, Annahmen basierend auf der Erweiterung genau treffen zu können. Daher ist es ratsam, ein leicht verständliches Regelwerk für Ihre Header-Dateien zu verwenden. Persönlich mache ich lieber so etwas:

1. Wenn bereits Richtlinien festgelegt sind, befolgen Sie diese, um Verwirrung zu vermeiden.
2. Wenn alle Quelldateien im Projekt dieselbe Sprache haben, verwenden Sie .h. Es gibt keine Mehrdeutigkeit.
3. Wenn einige Header mit mehreren Sprachen kompatibel sind, während andere nur mit einer einzigen Sprache kompatibel sind, basieren Erweiterungen auf der restriktivsten Sprache, mit der ein Header kompatibel ist. Ein Header, der mit C oder mit C & C ++ kompatibel ist, wird abgerufen.h , während ein Kopf kompatibel mit C ++ , aber nicht C bekommt .hppoder .hhoder etwas dergleichen.

Dies ist natürlich nur eine von vielen Möglichkeiten, mit Erweiterungen umzugehen, und Sie können Ihrem ersten Eindruck nicht unbedingt vertrauen, selbst wenn die Dinge einfach erscheinen. Ich habe zum Beispiel erwähnt, dass die Verwendung .hfür normale Header und .tppfür Header, die nur Definitionen für Elementfunktionen für Vorlagenklassen enthalten, wobei .hDateien, die Vorlagenklassen definieren, einschließlich usw., immer ein C ++ - Header sind. Und wieder einmal verwenden einige Leute.tpp Dateien, die ihre Elementfunktionen definieren (anstelle der .hKopfzeile, die beide direkt enthält Funktionsdeklaration und Definition). Zum Beispiel spiegeln viele Leute immer die Sprache des Headers in seiner Erweiterung wider, auch wenn keine Möglichkeit für Mehrdeutigkeiten besteht. für sie .hist immer ein C-Header und .hpp(oder.hh , oder.hxx.h für "Header, der einer Quelldatei zugeordnet ist" und .hppfür "Header mit allen inline definierten Funktionen".

In Anbetracht dessen würde der Hauptvorteil darin bestehen, Ihre Header konsistent im gleichen Stil zu benennen und diesen Stil für jeden, der Ihren Code untersucht, leicht erkennbar zu machen. Auf diese Weise kann jeder, der mit Ihrem üblichen Codierungsstil vertraut ist, mit nur einem flüchtigen Blick feststellen, was Sie mit einer bestimmten Erweiterung meinen.