Deze koptekst is alleen voor C++.

Als u in een C-module bent, probeer dan niet eens mee te nemen. Je zult het niet leuk vinden, want er wordt geen moeite gedaan om het C-vriendelijke (te veel verloren te maken, zoals functie overbelasting, naamruimten, enz.).

.H: C / C++ compatibele of zuivere C-headers

Deze koptekst kan worden opgenomen door zowel een C-bron en een C++ -bron, direct of indirect.

Het kan rechtstreeks opgenomen, worden beschermd door de __cplusplusmacro:

• , wat betekent dat, vanuit een C++ -gezichtspunt, de C-compatibele code wordt gedefinieerd als extern "C".
• van een C-gezichtspunt, alle C-code is duidelijk zichtbaar, maar de C++ -code is verborgen (omdat het niet in een C-compiler kan compileren).

Bijvoorbeeld:

#ifndef MY_HEADER_H
#define MY_HEADER_H
   #ifdef __cplusplus
      extern "C"
      {
   #endif
   void myCFunction() ;
   #ifdef __cplusplus
      } // extern "C"
   #endif
#endif // MY_HEADER_H

of het kan indirect worden opgenomen door de bijbehorende .HPP-koptekst die het bij de extern "C"-verklaring insluiten.

Bijvoorbeeld:

#ifndef MY_HEADER_HPP
#define MY_HEADER_HPP
extern "C"
{
#include "my_header.h"
}
#endif // MY_HEADER_HPP

en:

#ifndef MY_HEADER_H
#define MY_HEADER_H
void myCFunction() ;
#endif // MY_HEADER_H

Antwoord 3, Autoriteit 9%

Ik heb altijd beschouwd als de .hppkoptekst om een ​​soort van Portmanteau van .hen .cppbestanden te zijn … een kopteller die bevat ook implementatiedetails.

Typisch wanneer ik (en gebruikt) .hppals extensie heeft gezien, is er geen overeenkomstige .cppbestand. Zoals anderen hebben gezegd, is dit geen moeilijke en snelle regel, hoe ik de neiging heb om .hppbestanden te gebruiken.

Antwoord 4, Autoriteit 6%

Het maakt niet uit welke extensie u gebruikt. Ofwel is OK.

Ik gebruik *.hvoor C en *.hppvoor C++.

Antwoord 5, Autoriteit 5%

bewerken [Toegevoegd suggestie van Dan Nissenbaum]:

Door één conventie, .HPP-bestanden worden gebruikt wanneer de prototypen in de kop zelf zijn gedefinieerd. Dergelijke definities in headers zijn nuttig in geval van sjablonen, aangezien de compiler de code voor elk type alleen op sjablooninstantie genereert. Als ze niet worden gedefinieerd in header-bestanden, worden hun definities niet opgelost bij Link Time vanuit andere compilatie-eenheden. Als uw project een project voor alleen C++ is dat zwaar gebruik van sjablonen maakt, is dit verdrag nuttig.

Bepaalde sjabloonbibliotheken die zich aan dit verdrag hechten, bieden headers met .HPP-extensies om aan te geven dat ze geen overeenkomstige .cpp-bestanden hebben.

Een ander verdrag is om te gebruiken .h voor C-header en .hpp voor C++; Een goed voorbeeld zou de Boost-bibliotheek zijn.

Citaat van BOOST FAQ,

Bestandsextensies communiceren het “Type” van het bestand, zowel voor mensen
en op computerprogramma’s. De extensie ‘.h’ wordt gebruikt voor C-header
bestanden en communiceert daarom het verkeerde over C++ header
bestanden. Het gebruik van geen extensie communiceert niets en forces inspectie
van bestandsinhoud om het type te bepalen. Met behulp van ‘.hpp’ ondubbelzinnig
Identificeert het als C++ Header-bestand en werkt goed in de praktijk.
(Rainer deyke)

Antwoord 6, Autoriteit 3%

Ik beantwoord dit als een herinnering, om aan mijn reactie (s) te geven op “User1949346” antwoord op ditzelfde OP.

Dus zoveel al beantwoord: hoe dan ook is prima.
Gevolgd door benadrukt van hun eigen indrukken.

Inleidende, zoals ook in de vorige genoemde opmerkingen vermeld, is mijn mening C++Header-extensies voorgesteld als .hAls er eigenlijk geen reden is.

Aangezien de ISO / IEC-documenten deze notatie van header-bestanden gebruiken en geen string die overeenkomt met .hppvindt u zelfs plaats in hun taaldocumentaties over C++.

Maar ik ben nu gericht op een goedkeurbare reden waarom hoe dan ook ok is, en vooral waarom het niet onderwerp is van de taal die het zelf is.

Dus hier gaan we.

De C++DOCUMENTATIE (ik ben daadwerkelijk een verwijzing van de versie N3690) definieert dat een koptekst moet voldoen aan de volgende syntaxis:

2.9 kopnamen

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 "

Zoals we uit dit onderdeel kunnen uittrekken, kan de kopbalbestandsnaam iets zijn dat ook geldig is in de broncode. Behalve met '\n'tekens en afhankelijk van als het moet worden opgenomen door <>is het niet toegestaan ​​om een ​​>.
Of de andere manier als het wordt opgenomen door ""-include het is niet toegestaan ​​om een ​​"

te bevatten

Met andere woorden: als u een milieu had ondersteund bestandsnamen zoals prettyStupidIdea.>, een omvatten zoals:

#include "prettyStupidIdea.>"

zou geldig zijn, maar:

#include <prettyStupidIdea.>>

zou ongeldig zijn. Omgekeerd hetzelfde.

En zelfs

#include <<.<>

zou een geldige inclusieve header-bestandsnaam zijn.

Zelfs dit zou voldoen aan C++, het zou een behoorlijk dom idee zijn, dat wel.

En daarom is .hppook geldig.

Maar het is niet het resultaat van de commissies die beslissingen voor de taal ontwerpen!

Dus discussiëren over het gebruik van .hppis hetzelfde als doen over .cc, .mmof wat ik nog meer in andere berichten over dit onderwerp.

Ik moet toegeven dat ik geen idee heb waar .hppvandaan komt¹, maar ik durf te wedden dat een uitvinder van een of andere ontledingstool, IDE of iets anders dat te maken heeft met C++kwam op dit idee om enkele interne processen te optimaliseren of om (waarschijnlijk zelfs voor hen noodzakelijkerwijs) nieuwe naamgevingsconventies uit te vinden.

Maar het maakt geen deel uit van de taal.

En wanneer iemand besluit het op deze manier te gebruiken. Of het nu is omdat hij het het leukst vindt of omdat sommige toepassingen van de workflow het vereisen, het is nooit²een vereiste van de taal. Dus wie zegt “de pp is omdat het wordt gebruikt met C++”, heeft het gewoon bij het verkeerde eind met betrekking tot de taaldefinitie.

C++ staat alles toe dat de vorige paragraaf respecteert.
En als er iets is dat de commissie voorstelde te gebruiken, dan gebruikt het .haangezien dit de extensie is die in alle voorbeelden van het ISO-document wordt aangeklaagd.

Conclusie:

Zolang je het gebruik van .hover .hppof vice versa niet ziet/voelt, hoef je je geen zorgen te maken. Omdat beide een geldige headernaam zouden vormen van dezelfde kwaliteit met betrekking tot de standaard. En daarom is alles wat u VEREISTom .hof .hppte gebruiken een aanvullende beperking van de standaard die zelfs in tegenspraak zou kunnen zijn met andere aanvullende beperkingen niet met elkaar overeenkomen. Maar aangezien OP geen aanvullende taalbeperking vermeldt, is dit het enige juiste en goedgekeurde antwoord op de vraag

“*.h of *.hpp voor uw klassendefinities” is:

Beide zijn even correct en van toepassing zolang er geen externe beperkingen aanwezig zijn.

¹_{Voor zover ik weet, is het blijkbaar het boost-framework dat met die extensie .hppkwam.}

²_{Natuurlijk kan ik niet zeggen wat sommige toekomstige versies met zich mee zullen brengen!}

Antwoord 7, autoriteit 2%

Ik ben onlangs begonnen met het gebruik van *.hppvoor c++-headers.

De reden is dat ik emacs als mijn primaire editor gebruik en het automatisch in c-mode gaat als je een *.hbestand laadt en in c++-mode als je een *.hpp-bestand.

Behalve dat feit zie ik geen goede redenen om *.hte verkiezen boven *.hppof omgekeerd.

Antwoord 8

U kunt uw omvat noemen wat u maar wilt.

Je hoeft alleen die volledige naam op te geven in de #include.

Ik stel voor dat als je met C werkt om .hte gebruiken en wanneer met C++ om .hppte gebruiken.

Het is uiteindelijk maar een conventie.

Antwoord 9

Ik geef de voorkeur aan .hpp voor C++ om zowel redacteuren als andere programmeurs duidelijk te maken dat het een C++-header is in plaats van een C-headerbestand.

Antwoord 10

C++ (“C plus plus”) is logisch als .cpp

Met kopbestanden met een .HPP-extensie heeft niet dezelfde logische stroom.

Antwoord 11

CODEGEAR C++ Builder gebruikt .Hpp voor header-bestanden automagaal gegenereerd uit Delphi-bronbestanden en .h-bestanden voor uw “eigen” header-bestanden.

Dus, wanneer ik een C++ header-bestand schrijf, gebruik ik altijd .h.

Antwoord 12

In een van mijn banen in de vroege jaren 90 gebruikten we .cc en .hh voor respectievelijk bron- en header-bestanden. Ik geef er nog steeds de voorkeur aan alternatieven, waarschijnlijk omdat het het gemakkelijkst is om te typen.

Antwoord 13

Bjarne Stroustrup en Herb Sutter hebben een verklaring aan deze vraag in hun C++ Core-richtlijnen gevonden op: https://github.com/isocpp/cppcoreguidelines/blob/master/cppcoreguidelines.md#-source die ook naar de laatste wijzigingen in de standaardextensie verwijst (C++ 11, C++ 14, enz.)

SF.1: Gebruik een .cpp suffix voor codebestanden en .h voor interfacebestanden als uw
Y-project volgt niet al een andere conventie
Reden

Het is een langdurige conventie. Maar de consistentie is belangrijker, dus als
Je project gebruikt iets anders, volg dat.
OPMERKING

Dit conventie weerspiegelt een gemeenschappelijk gebruikpatroon: kopers worden vaker gedeeld
met C om te compileren als zowel C++ als C, die meestal gebruikt .h, en het is
gemakkelijker om alle headers te noemen .h in plaats van verschillende extensies voor te hebben
Alleen die headers die bedoeld zijn om te worden gedeeld met C. aan de andere kant,
Implementatiebestanden worden zelden gedeeld met C en moeten meestal meestal zijn
Distinguished from .c-bestanden, dus het is normaal dat het beste is om alle C++ te noemen
Implementatiebestanden iets anders (zoals .cpp).

De specifieke namen .h en .cpp zijn niet vereist (gewoon aanbevolen als een
standaard) en andere namen worden veel gebruikt. Voorbeelden zijn .hh, .C en
.cxx. Gebruik dergelijke namen gelijkwaardig. In dit document verwijzen we naar .h en .cpp > als een afkorting voor header- en implementatiebestanden, hoewel de werkelijke
extensie kan anders zijn.

Uw IDE (als u er een gebruikt) kan een uitgesproken mening hebben over voldoende.

Ik ben geen grote fan van deze conventie, want als je een populaire bibliotheek zoals boost gebruikt, is je consistentie al verbroken en kun je beter .hpp gebruiken.

Antwoord 14

Zoals velen hier al hebben vermeld, gebruik ik ook liever .hpp voor bibliotheken met alleen headers die sjabloonklassen/-functies gebruiken. Ik gebruik het liefst .h voor headerbestanden die vergezeld gaan van .cpp-bronbestanden of gedeelde of statische bibliotheken.

De meeste bibliotheken die ik ontwikkel, zijn gebaseerd op sjablonen en hoeven dus alleen een header te zijn, maar bij het schrijven van applicaties heb ik de neiging om declaratie te scheiden van de implementatie en eindigen met .h- en .cpp-bestanden

Antwoord 15

Gelukkig is het eenvoudig.

Je moet de .hpp-extensie gebruiken als je met C++ werkt en je moet .h gebruiken voor C of C en C++ mixen.

Antwoord 16

Ik gebruik .h omdat dat is wat Microsoft gebruikt en wat hun codegenerator maakt. Het is niet nodig om tegen de stroom in te gaan.

Antwoord 17

Het is gemakkelijk voor tools en mensen om ietste onderscheiden. Dat is het.

Bij conventioneel gebruik (door boost, enz.), is .hppspecifiek C++-headers. Aan de andere kant is .hvoor niet-C++-only headers (voornamelijk C). Het is over het algemeen moeilijk om de taal van de inhoud precies te detecteren, omdat er veel niet-triviale gevallen zijn, dus dit verschil maakt een kant-en-klaar hulpmiddel vaak gemakkelijk om te schrijven. Voor mensen, als ze eenmaal de conventie hebben gekregen, is het ook gemakkelijk te onthouden en gemakkelijk te gebruiken.

Ik wil u er echter op wijzen dat de conventie zelf niet altijd werkt, zoals verwacht.

• Het wordt niet gedwongen door de specificatie van talen, noch C noch C++. Er zijn veel projecten die de conventie niet volgen. Als je ze eenmaal moet samenvoegen (om ze te mixen), kan dat lastig zijn.
• .hppzelf is niet de enige keuze. Waarom niet .hhof .hxx? (Hoewel hoe dan ook, je hebt meestal minstens één conventionele regel nodig over bestandsnamen en paden.)

Ik gebruik persoonlijk zowel .hals .hppin mijn C++-projecten. Ik volg de bovenstaande conventie niet omdat:

• De talen die door elk deel van de projecten worden gebruikt, zijn expliciet gedocumenteerd. Geen kans om C en C++ in dezelfde module (directory) te mixen. Elke bibliotheek van derden moet aan deze regel voldoen.
• De conforme taalspecificaties en toegestane taaldialecten die door de projecten worden gebruikt, zijn ook gedocumenteerd. (In feite documenteer ik zelfs de bron van de standaardfuncties en bugfix ( op de taalstandaard) die wordt gebruikt.) Dit is iets belangrijker dan het onderscheiden van de gebruikte talen, omdat het te foutgevoelig is en de testkosten (bijv. Compatibiliteit met compilers) aanzienlijk kunnen zijn (ingewikkeld en tijdrovend) , vooral in een project dat al in bijna pureC++ is. Bestandsnamen zijn te zwak om dit aan te kunnen.
• Zelfs voor hetzelfde C++-dialect kunnen er belangrijkere eigenschappen zijn die geschikt zijn voor het verschil. Zie bijvoorbeeld de conventie hieronder.
• Bestandsnamen zijn in wezen stukjes kwetsbare metadata. De schending van het verdrag is niet zo gemakkelijk op te sporen. Om stabiel met de inhoud om te gaan, moet een tool uiteindelijk niet alleen afhankelijk zijn van namen. Het verschil tussen extensies is slechts een hint. Van tools die het gebruiken, moet ook niet worden verwacht dat ze zich altijd hetzelfde gedragen, b.v. taaldetectie van .hbestanden op github.com. (Er kan iets in opmerkingen als shebangstaan zodat deze bronbestanden betere metadata zijn, maar het is zelfs niet conventioneel zoals bestandsnamen, dus ook niet betrouwbaar in het algemeen.)

Ik gebruik meestal .hppop C++-headers en de headers moeten worden gebruikt (onderhouden) op een alleen-header-manier, b.v. als sjabloonbibliotheken. Voor andere headers in .his er ofwel een bijbehorend .cpp-bestand als implementatie, of het is een niet-C++-header. Dit laatste is triviaal om te differentiëren door de inhoud van de header door mensen (of door tools met expliciete ingesloten metadata, indien nodig).

Antwoord 18

In “The C++ Programming Language, Third Edition by Bjarne Stroustrup”, het nummer 1 must-read C++-boek, gebruikt hij *.h. Dus ik neem aan dat het het beste is om *.h te gebruiken.

Maar *.hpp is ook prima!

Antwoord 19

De extensie van het bronbestand kan betekenis hebben voor uw bouwsysteem, u kunt bijvoorbeeld een regel in uw makefile hebben voor .cpp– of .c-bestanden, of uw compiler (bijv. Microsoft cl.exe) kan het bestand compileren als C of C++, afhankelijk van de extensie.

Omdat je de hele bestandsnaam moet opgeven voor de #include-instructie, is de bestandsextensie van de header niet relevant. Je kunt desgewenst een .c-bestand in een ander bronbestand opnemen, omdat het slechts een tekstuele opname is. Uw compiler heeft mogelijk een optie om de voorverwerkte uitvoer te dumpen, wat dit duidelijk maakt (Microsoft: /Pom voor te verwerken naar bestand, /Eom voor te verwerken naar stdout, /EPom #linerichtlijnen weg te laten, /Com opmerkingen te behouden)

U kunt ervoor kiezen om .hppte gebruiken voor bestanden die alleen relevant zijn voor de C++-omgeving, d.w.z. ze gebruiken functies die niet in C kunnen worden gecompileerd.

Antwoord 20

Er is geen voordeel aan een bepaalde extensie, behalve dat een extensie een andere betekenis kan hebben voor jou, de compiler en/of je tools. header.his een geldige header. header.hppis een geldige header. header.hhis een geldige header. header.hxis een geldige header. h.headeris een geldige header. this.is.not.a.valid.headeris een geldige header in ontkenning. ihjkflajfajfklafis een geldige header. Zolang de naam goed kan worden geparseerd door de compiler en het bestandssysteem het ondersteunt, is het een geldige header, en het enige voordeel van de extensie is wat men erin leest.

Dat gezegd hebbende, is het erghandig om nauwkeurig aannames te kunnen doen op basis van de extensie, dus het zou verstandig zijn om een gemakkelijk te begrijpen set regels voor je header-bestanden te gebruiken. Persoonlijk geef ik er de voorkeur aan om zoiets als dit te doen:

1. Als er al richtlijnen zijn, volg deze dan om verwarring te voorkomen.
2. Als alle bronbestanden in het project voor dezelfde taal zijn, gebruik dan .h. Er is geen dubbelzinnigheid.
3. Als sommige koppen compatibel zijn met meerdere talen, terwijl andere alleen compatibel zijn met één taal, zijn extensies gebaseerd op de meest beperkende taal waarmee een koptekst compatibel is. Een header die compatibel is met C, of met zowel C & C++ krijgt .h, terwijl een header die compatibel is met C++ maar niet met C .hppof .hhof iets dergelijks krijgt.

Dit is natuurlijk maar een van de velemanieren om met extensies om te gaan, en u kunt uw eerste indruk niet per se vertrouwen, zelfs als de zaken eenvoudig lijken. Ik heb bijvoorbeeld een melding gezien van het gebruik van .hvoor normale headers, en .tppvoor headers die alleen definities bevatten voor sjablonen voor klassenlidfuncties, met .h-bestanden die sjabloonklassen definiëren, inclusief de .tpp-bestanden die hun lidfuncties definiëren (in plaats van de .h-header die direct zowel de functiedeclaratie als de definitie bevat ). Een ander voorbeeld: heel wat mensen weerspiegelen altijd de taal van de koptekst in de extensie, zelfs als er geen kans op dubbelzinnigheid is; voor hen is .haltijd een C-header en .hpp(of .hh, of .hxx, etc.) is altijd een C++-header. En nogmaals, sommige mensen gebruiken .hvoor “header gekoppeld aan een bronbestand” en .hppvoor “header met alle functies inline gedefinieerd”.

Als je dit in overweging neemt, zou het belangrijkste voordeel zijn dat je je headers consequent in dezelfde stijl noemt, en die stijl duidelijk maakt voor iedereen die je code onderzoekt. Op deze manier kan iedereen die bekend is met uw gebruikelijke codeerstijl in een vluchtige blik bepalen wat u bedoelt met een bepaalde extensie.