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

https://stackoverflow.com/questions/152555

c++
Header

02-07-2019
|

Frage

Ich habe früher immer eine *.h Datei für meine Klassendefinitionen, aber einige boost Bibliothekscode nach dem Lesen, erkannte ich, sie alle verwenden *.hpp. Ich habe immer eine Abneigung gegen diese Dateierweiterung hatte, glaube ich, vor allem, weil ich es nicht gewohnt bin.

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

Lösung

Hier sind ein paar Gründe für unterschiedliche Benennung von C vs C ++ Header mit:

Automatische Code-Formatierung, können Sie verschiedene Richtlinien haben für die Formatierung von C und C ++ Code. Wenn die Header durch Erweiterung getrennt sind, können Sie Ihren Editor stellen Sie die entsprechende Formatierung automatisch anwenden
Naming, ich habe an Projekten, in denen es Bibliotheken in C geschrieben wurden und dann in C implementiert Wrapper hatte ++. Da die Header in der Regel ähnliche Namen hatte, das heißt feature.h vs Feature.hpp, waren sie leicht auseinander zu halten.
Aufnahme, vielleicht Ihr Projekt hat geeignetere Versionen in C ++ geschrieben, aber Sie werden mit der C-Version (siehe oben Punkt). Wenn Header nach der Sprache benannt werden sie in Ihnen leicht umgesetzt werden können alle C-Header erkennen und prüfen für C ++ Versionen.

Denken Sie daran, C ist nicht C ++ und es kann sehr gefährlich sein, zu mischen und anzupassen, wenn Sie wissen, was Sie tun. Benennen geeigneter Weise Ihre Quellen hilft Ihnen, die Sprachen auseinander halten.

Andere Tipps

Ich benutze .hpp weil ich den Benutzer unterscheiden wollen, welche Header sind C ++ Header und welche Header sind C-Header.

Dies kann wichtig sein, wenn Ihr Projekt sowohl C und C ++ Module ist mit: Wie jemand anderes vor mir erklärt, sollten Sie es tun, sehr sorgfältig, und seine beginnt mit dem „Vertrag“ Sie bieten durch die Erweiterung

.hpp: C ++ Header

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

Dieser Header ist für C ++ nur.

Wenn Sie in einem C-Modul sind, nicht einmal versuchen, es zu schließen. Sie werden es nicht mögen, weil keine Mühe zu machen, geschieht es C-freundlich (wäre zu viel verloren, wie Überladen von Funktionen, Namensräume usw. usw.).

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

Dieser Header kann sowohl eine C-Quelle enthalten sein und eine C ++ Quelle, direkt oder indirekt.

Es kann direkt enthalten, durch die __cplusplus Makro geschützt werden:

was bedeutet, dass aus einer C ++ Sicht der C-kompatiblen Code wird als extern "C" definiert werden.
Aus einer C Sicht all C-Code wird deutlich sichtbar sein, aber der C ++ Code wird ausgeblendet werden (weil es nicht in einem C-Compiler kompiliert).

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 durch den entsprechenden .hpp Header enthält indirekt könnte es mit der extern "C" Erklärung einschließen.

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 immer der .hpp Header als eine Art Kunstwort aus .h und .cpp Dateien ... einen Header zu sein, die auch Implementierungsdetails enthalten.

Normalerweise, wenn ich (und Verwendung) .hpp als Erweiterung gesehen habe, gibt es keine entsprechende .cpp Datei. Wie andere gesagt haben, ist dies nicht eine harte und schnelle Regel nur, wie ich neige .hpp Dateien zu verwenden.

Es ist egal, welche Erweiterung, die Sie verwenden. Entweder man ist OK.

Ich verwende *.h für C und *.hpp für C ++.

Bearbeiten [Hinzugefügt Vorschlag von Dan Nissenbaum]:

Nach einer Konvention werden .hpp Dateien verwendet, wenn die Prototypen im Header selbst definiert sind. Solche Definitionen in Header sind in dem Fall von Schablonen nützlich, da der Compiler für jede Art des Codes erzeugt nur auf Vorlage Instanziierung. Daher, wenn sie nicht in der Header-Dateien definiert sind, ihre Definitionen nicht zur Verknüpfungszeit von anderen Übersetzungseinheiten aufgelöst werden. Wenn Ihr Projekt ein C ++ einziges Projekt, das die starke Nutzung von Vorlagen macht, könnte diese Konvention nützlich sein.

Einige Template-Bibliotheken, die zu dieser Konvention einzuhalten bieten Header mit .hpp Erweiterungen, um anzuzeigen, dass sie nicht über Dateien entsprechenden CPP.

Einige andere Template-Bibliotheken verwenden eine andere Konvention, wie mit .h für C-Header und .hpp für C ++; Ein gutes Beispiel wäre die Boost-Bibliothek sein.

Zitat von Boost-FAQ,

Dateierweiterungen kommunizieren, um den „Typen“ der Datei, die beide auf den Menschen   und auf Computerprogramme. Die ‚.h‘ Erweiterung für C-Header verwendet   Dateien und damit in Verbindung stehen, die falsche Sache über C ++ Header   Dateien. keine Erweiterung Mit kommuniziert nichts und Kräfte Inspektion   Inhaltsdateityp zu bestimmen. Mit ‚.hpp‘ eindeutig   identifiziert es als C ++ Header-Datei, und funktioniert gut in der Praxis.   (Rainer Denkt)

Ich habe vor kurzem begonnen *.hpp für c ++ Header verwendet wird.

Der Grund dafür ist, dass ich Emacs als mein primärer Editor verwenden, und es tritt automatisch in c-Modus, wenn Sie eine *.h Datei laden und in C ++ - Modus, wenn Sie eine *.hpp Datei laden.

Neben dieser Tatsache habe ich keine guten Gründe sehen *.h über *.hpp oder umgekehrt entschieden haben.

Ich beantworte diese als Erinnerung, zeigen Sie auf meinen Kommentar (e) auf „user1949346“ Antwort auf diese gleiche OP zu geben.

So wie viele bereits beantwortet: So oder so ist in Ordnung. Gefolgt von betont ihre eigenen Eindrücke.

Einführungs-, wie auch in den vorherigen Namen Kommentare angegeben, meiner Meinung nach ist C++ Header-Erweiterungen vorgeschlagen .h werden, wenn es eigentlich keinen Grund, dagegen ist.

Da die ISO / IEC-Dokumente diese Notation von Header-Dateien verwenden und kein String-Matching .hpp tritt auch in ihrer Sprache Dokumentationen über C++.

Aber ich bin mit dem Ziel jetzt einen approvable Grund, warum so oder so in Ordnung ist, und vor allem, warum es nicht Gegenstand der Sprache selbst ein.

So, hier gehen wir.

Die C++ Dokumentation (ich bin eigentlich Referenz von der Version N3690 nehmen) legt fest, dass ein Header der folgenden Syntax entsprechen muss:

2.9 Header-Name

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 "

So wie wir aus diesem Teil extrahieren können, kann der Header-Datei Name alles sein, das im Quelltext auch gültig ist. Außer '\n' Zeichen enthält, und je nachdem, ob es durch <> aufgenommen werden wird kein > enthalten darf. Oder anders, wenn es von eingeschlossen ist ""-ist, nicht erlaubt, ein " enthalten.

Mit anderen Worten: Wenn Sie eine Umgebung haben Dateinamen wie prettyStupidIdea.> unterstützt, eine umfassen wie:

#include "prettyStupidIdea.>"

wäre gültig, aber:

#include <prettyStupidIdea.>>

wäre ungültig. Der andere Weg, um die gleiche.

Und selbst

#include <<.<>

würde ein gültiger includable Header-Datei-Name sein.

Auch würde dies entsprechen C++, es ist eine ziemlich ziemlich dumme Idee, tho sein würde.

Und deshalb .hpp gültig ist, auch.

Aber es ist nicht ein Ergebnis der Ausschüsse Entscheidungen für die Sprache entwerfen!

über So diskutiert die Verwendung .hpp ist so, wie es etwa .cc tun, .mm oder was auch immer sonst las ich in anderen Beiträgen zu diesem Thema.

Ich muss zugeben, dass ich keine Ahnung, wo .hpp kam von ¹, aber ich würde ein Erfinder einiger Parsing-Tool, IDE oder etwas anderes besorgt mit C++ Wette kam auf diese Idee, einige interne Optimierung Prozesse oder nur einige (wahrscheinlich sogar für sie notwendigerweise) neue Namenskonventionen zu erfinden.

Aber es ist nicht Teil der Sprache.

Und wenn man entscheidet, es auf diese Weise zu verwenden. Kann es sein, weil er es am meisten, oder weil einige Anwendungen des Workflows es erfordern mag, es nie ² eine Anforderung der Sprache ist. Wer also sagt: „Die PP ist, weil es mit C ++ verwendet wird“, ist einfach falsch in Bezug auf die Sprachen-Definition.

C ++ ermöglicht es etwas vorhergehenden Absatz zu respektieren. Und wenn es etwas gibt, das Komitee vorgeschlagen, zu verwenden, dann ist es .h verwenden, da dies die Erweiterung in allen Beispielen des ISO-Dokuments verklagt wird.

Fazit:

So lange Sie keine Notwendigkeit der Verwendung .h über .hpp oder umgekehrt sehen / fühlen, sollten Sie nicht stören. Da beide sein würden, einen gültigen Header-Namen von gleicher Qualität in Bezug auf die Standards bilden. Und deshalb alles, was BRAUCHT Sie verwenden .h oder .hpp ist eine zusätzliche Beschränkung der Norm, die auch mit anderen zusätzlichen Einschränkungen werden im Widerspruch konnte nicht miteinander übereinstimmen. Aber als OP keine zusätzliche Sprache Einschränkung erwähnt, ist dies die einzig richtige und genehmigungs Antwort auf die Frage

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

Beide sind gleichermaßen korrekt und anwendbar, solange keine äußeren Einschränkungen vorhanden sind.

¹ _{Von dem, was ich weiß, es scheint, ist es der Verstärkungsrahmen, der mit dieser .hpp Erweiterung kam.}

² _{Natürlich habe ich nicht, was einige zukünftige Versionen bringen damit sagen kann!}

Ich ziehe .hpp für C ++, um es zu beiden Editoren und anderen Programmierer zu machen deutlich, dass es sich um einen C ++ Header statt einer C-Header-Datei.

C ++ ( "C Plus Plus") macht Sinn, als CPP

Mit Header-Dateien mit einer .hpp Erweiterung nicht den gleichen logischen Fluss.

Sie können rufen Sie enthält alles, was Sie möchten.

Nur müssen die vollständigen Namen in der #include angeben.

Ich schlage vor, dass, wenn Sie mit C arbeiten .h zu verwenden, und wenn es mit C ++ .hpp zu verwenden.

Es ist am Ende nur eine Konvention.

CodeGear C ++ Builder verwendet .hpp für Header-Dateien automatisch generierten aus Delphi-Quelldateien und H-Dateien für Ihre „eigenen“ Header-Dateien.

Also, wenn ich eine C ++ Header-Datei Ich schreibe verwende ich immer .h.

In einem meiner Arbeitsplätze in den frühen 90er Jahren, haben wir .cc und .hh für Quelle und Header-Dateien sind. Ich ziehe es immer noch über alle Alternativen, wahrscheinlich, weil es am einfachsten zu geben.

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

SF.1: eine CPP-Suffix für Code-Dateien verwenden und für Schnittstellendateien .h, wenn Ihr   Y Projekt folgt nicht bereits eine andere Konvention   Begründung

Es ist eine langjährige Konvention. Aber Konsistenz ist wichtiger, so dass, wenn   Ihr Projekt verwendet etwas anderes folgen, dass.   Hinweis:

Diese Konvention ist auf ein gemeinsames Einsatzmuster: Vorsätze sind häufiger geteilt   mit C sowohl als C ++ und C, zu kompilieren, die in der Regel · h verwendet, und es ist   einfacher alle Header zu nennen · H anstelle verschiedene Erweiterungen, die für   nur jene Header, die mit C. Auf der anderen Seite gemeinsam genutzt werden sollen,   Implementierungsdateien werden nur selten mit C geteilt und so sollte in der Regel   unterscheidet sich von .c-Dateien, so dass es in der Regel am besten, alle C ++ zu nennen   Implementierungsdateien etwas anderes (wie CPP).

Die spezifischen Namen .h und CPP nicht erforderlich ist (wie ein empfohlenes   default) und andere Namen sind weit verbreitet. Beispiele sind .hh, .C, und   .cxx. Verwenden Sie in äquivalenter Weise solche Namen. In diesem Dokument verweisen wir auf .h und CPP> als Abkürzung für Header und Implementierungsdateien, auch wenn die tatsächlichen   Erweiterung kann unterschiedlich sein.

Ihr IDE (falls Sie eine verwenden) haben starke Meinungen über genügt.

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

Wie hier viele haben bereits erwähnt, ziehe ich es auch .hpp für Kopf nur Bibliotheken, die Template-Klassen / Funktionen verwenden. Ich ziehe es für Header-Dateien von CPP-Quelldateien oder gemeinsam genutzte oder statische Bibliotheken begleitet verwenden .h.

Die meisten der Bibliotheken, die ich entwickeln sind Vorlage basiert und somit nur Header werden müssen, aber wenn Anwendungen zu schreiben neige ich dazu, Erklärung von Implementierung zu trennen und mit .h und CPP-Dateien am Ende

Glücklicherweise ist es einfach.

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

Ich verwende .h, weil das ist, was Microsoft verwendet, und was ihr Code-Generator erzeugt. Keine Notwendigkeit, gegen den Strich zu gehen.

"Die C ++ Programmiersprache, dritte Ausgabe von Bjarne Stroustrup", die nº1 must-read C ++ Buch verwendet er * .h. Also nehme ich an die beste Praxis * .h zu verwenden ist.

Allerdings * .hpp ist auch gut!

Es ist leicht, für Werkzeuge und Menschen zu unterscheiden etwas . Das ist es.

Bei der herkömmlichen Verwendung (von Boost, etc.), .hpp ist speziell C ++ Header. Auf der anderen Seite ist .h für Nicht-C ++ - nur Header (vor allem C). Um genau die Sprache des Inhalts zu erkennen im Allgemeinen schwierig ist, da es viele nicht-trivialen Fälle sind, so dass dieser Unterschied macht oft ein ready-to-use-Tool leicht zu schreiben. Für die Menschen, wenn die Konvention bekommen, ist es auch leicht zu merken und einfach zu bedienen.

Allerdings würde ich die Konvention selbst darauf hin, nicht immer funktioniert, wie erwartet.

Es ist nicht durch die Angabe von Sprachen , weder C noch C ++ gezwungen. Es gibt viele Projekte, die die Konvention nicht folgen. Sobald Sie zusammenführen müssen (mischen), sie kann es mühsam sein.
.hpp selbst ist nicht die einzige Wahl. Warum .hh oder .hxx nicht? (Obwohl sowieso, müssen Sie in der Regel mindestens eine herkömmliche Regel über Dateinamen und Pfade.)

Ich persönlich benutze sowohl .h und .hpp in meinen C ++ Projekten. Ich folge nicht der Konvention über weil:

Die Sprachen, die von jedem Teil der Projekte verwendet werden explizit dokumentiert. Keine Chance C und C ++ in demselben Modul (Verzeichnis) zu mischen. Jede 3rdparty Bibliothek ist erforderlich, um diese Regel zu entsprechen.
Die angeglichene Sprache Spezifikationen und erlaubt Sprache Dialekte von den Projekten verwendet werden, ebenfalls dokumentiert. (In der Tat dokumentieren ich auch der Quelle der Standard-Features und Bug-Fix ( auf dem Sprachstandard) verwendet werden.) das ist etwas wichtiger als die verwendeten Sprachen zu unterscheiden, da es zu fehleranfällig und die Kosten der Prüfung (zB Compiler-Kompatibilität) ist von Bedeutung sein kann (kompliziert und zeitaufwendig) , vor allem in einem Projekt, das bereits in ist fast rein C ++. Die Dateinamen sind zu schwach, dies zu umgehen.
Auch für den gleichen C ++ Dialekt, kann es mehr wichtige Eigenschaften geeignet, um die Differenz. Zum Beispiel finden Sie in der Konvention unter.
Die Dateinamen sind im wesentlichen Stücke fragiler Metadaten. Die Verletzung der Konvention ist nicht so leicht zu erkennen. Stabil zu sein, den Inhalt zu tun, sollte ein Werkzeug schließlich nicht nur auf Namen abhängen. Der Unterschied zwischen den Verlängerungen ist nur ein Hinweis. Werkzeuge, die es verwenden, sollten auch nicht so tun gleiche die ganze Zeit erwartet werden, zum Beispiel Spracherkennungs von .h Dateien auf github.com. (Es kann etwas in Kommentaren wie sheBANG für diese Quelldateien besser Metadaten zu sein, aber es ist auch nicht konventionell wie Dateinamen, so auch nicht zuverlässig im allgemeinen.)

Normalerweise verwende ich .hpp auf C ++ Header und die Header sollen (gehalten) in einer Kopf nur Art und Weise, beispielsweise verwendet werden, als Template-Bibliotheken. Für andere Header in .h, entweder gibt es eine entsprechende .cpp Datei als Implementierung oder es ist eine Nicht-C ++ Header. Letztere trivial ist durch den Menschen durch den Inhalt des Headers zu unterscheiden (oder durch Tools mit expliziten eingebetteten Metadaten, falls erforderlich).

Die Erweiterung der Quelldatei kann auf Ihr Build-System Bedeutung hat, beispielsweise eine Regel in Ihrer Make-Datei für .cpp oder .c Dateien haben könnte, oder die Compiler (zB Microsoft cl.exe) könnte die Datei als C oder C ++ kompiliert je nach der Erweiterung.

Da Sie die gesamten Dateinamen in der #include Richtlinie zur Verfügung stellen müssen, ist die Header-Datei Erweiterung irrelevant. Sie können eine .c Datei in einer anderen Quelldatei enthalten, wenn Sie mögen, denn es ist nur ein Text ist. Ihr Compiler könnte eine Option, die Präprozessorausgabe abzuladen, die dies deutlich machen wird (Microsoft: /P vorverarbeitet Datei, /E vorverarbeiten stdout, /EP #line Richtlinien wegzulassen, /C Kommentare zu behalten)

Sie können wählen, .hpp für Dateien zu verwenden, die nur relevant für die C ++ Umgebung sind, das heißt, sie Funktionen nutzen, die nicht in C kompilieren.

Es gibt keinen Vorteil auf eine bestimmte Erweiterung, außer dass man möglicherweise eine andere Bedeutung für Sie haben, den Compiler und / oder Ihre Werkzeuge. header.h ist ein gültiger Header. header.hpp ist ein gültiger Header. header.hh ist ein gültiger Header. header.hx ist ein gültiger Header. h.header ist ein gültiger Header. this.is.not.a.valid.header ist ein gültiger Header in der Ablehnung. ihjkflajfajfklaf ist ein gültiger Header. Solange der Name richtig vom Compiler analysiert werden kann, und das Dateisystem unterstützt, es ist ein gültiger Header, und der einzige Vorteil seiner Ausdehnung ist, was man in sie liest.

aber sagte, dass genau in der Lage, Annahmen auf der Grundlage der Erweiterung ist sehr nützlich, so wäre es klug, einen leicht verständlichen Satz von Regeln für die Header-Dateien zu verwenden. Persönlich bevorzuge ich, so etwas zu tun:

Wenn bereits alle festgelegten Richtlinien sind, folgen sie Verwirrung zu vermeiden.
Wenn alle Quelldateien im Projekt sind für die gleiche Sprache, Verwendung .h. Es gibt keine Zweideutigkeit.
Wenn einige Header mit mehreren Sprachen kompatibel sind, während andere nur kompatibel mit einer einzigen Sprache sind, Erweiterungen sind auf der restriktivsten Auszeichnungssprache, die ein Header mit kompatibel ist. Ein Header kompatibel mit C oder mit beiden C & C ++, bekommt .h, während ein Kopf kompatibel mit C ++, aber nicht C .hpp oder .hh oder etwas Derartiges wird.

Dies ist natürlich nur eine von viele Möglichkeiten, Erweiterungen zu handhaben, und Sie können Ihren ersten Eindruck nicht unbedingt vertrauen, auch wenn die Dinge einfach zu sein scheinen. Zum Beispiel habe ich erwähnt mit .h für normale Header gesehen, und .tpp für Header, die nur Definitionen für Templat-Klasse Member-Funktionen enthalten, mit .h Dateien, die als Templat Klassen einschließlich den .tpp Dateien definieren, die ihre Elementfunktionen definieren (anstelle der .h header direkt sowohl die Funktionsdeklaration und die Definition enthält). Für ein weiteres Beispiel, spiegeln ein guter viele Menschen immer die Sprache der Header in seiner Ausdehnung, auch wenn es keine Chance der Mehrdeutigkeit ist; zu ihnen ist .h immer ein C-Header und .hpp (oder .hh oder .hxx, etc.) ist immer ein C ++ Header. Und noch einmal, verwenden manche Leute .h für „Header mit einer Quelldatei zugeordnet“ und .hpp für „Header mit allen Funktionen definiert inline“.

Diese Erwägung, würde der Hauptvorteil kommt in konsequent Ihre Header im gleichen Stil zu nennen, und macht, dass Stil zu jedermann leicht ersichtlich, Ihren Code zu untersuchen. Auf diese Weise kann jeder vertraut mit Ihrem üblichen Programmierstil wird in der Lage sein, zu bestimmen, was Sie mit nur einem flüchtigen Blick mit einer bestimmten Erweiterung bedeuten.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow