J'ai toujours utilisé un *.hfichier pour mes définitions de classe, mais après avoir lu du code de bibliothèque boost, j'ai réalisé qu'ils utilisaient tous *.hpp. J'ai toujours eu une aversion pour cette extension de fichier, je pense principalement parce que je n'y suis pas habitué.

Quels sont les avantages et les inconvénients d'utiliser *.hppplus *.h?

Voici quelques raisons pour avoir une dénomination différente des en-têtes C vs C ++:

• Formatage automatique du code, vous pouvez avoir des directives différentes pour le formatage du code C et C ++. Si les en-têtes sont séparés par extension, vous pouvez configurer votre éditeur pour appliquer automatiquement la mise en forme appropriée
• Nommer, j'ai été sur des projets où il y avait des bibliothèques écrites en C et ensuite les wrappers avaient été implémentés en C ++. Étant donné que les en-têtes avaient généralement des noms similaires, c'est-à-dire Feature.h vs Feature.hpp, ils étaient faciles à distinguer.
• Inclusion, votre projet peut avoir des versions plus appropriées disponibles écrites en C ++ mais vous utilisez la version C (voir le point ci-dessus). Si les en-têtes sont nommés d'après le langage dans lequel ils sont implémentés, vous pouvez facilement repérer tous les en-têtes C et rechercher les versions C ++.

Rappelez-vous, C n'est pas C ++ et il peut être très dangereux de mélanger et assortir à moins que vous sachiez ce que vous faites. Nommer correctement vos sources vous aide à distinguer les langues.

J'utilise .hpp parce que je veux que l'utilisateur différencie quels en-têtes sont des en-têtes C ++ et quels en-têtes sont des en-têtes C.

Cela peut être important lorsque votre projet utilise à la fois des modules C et C ++: comme quelqu'un d'autre l'a expliqué avant moi, vous devez le faire très soigneusement, et cela commence par le «contrat» que vous proposez via l'extension

.hpp: en-têtes C ++

(Ou .hxx, ou .hh, ou autre)

Cet en-tête est uniquement pour C ++.

Si vous êtes dans un module C, n'essayez même pas de l'inclure. Vous ne l'aimerez pas, car aucun effort n'est fait pour le rendre compatible C (trop serait perdu, comme la surcharge de fonctions, les espaces de noms, etc., etc.).

.h: en-têtes C compatibles ou purs C / C ++

Cet en-tête peut être inclus à la fois par une source C et par une source C ++, directement ou indirectement.

Il peut être inclus directement, étant protégé par la __cplusplusmacro:

• Ce qui signifie que, d'un point de vue C ++, le code compatible C sera défini comme extern "C".
• D'un point de vue C, tout le code C sera clairement visible, mais le code C ++ sera caché (car il ne compilera pas dans un compilateur C).

Par exemple:

#ifndef MY_HEADER_H
#define MY_HEADER_H

   #ifdef __cplusplus
      extern "C"
      {
   #endif

   void myCFunction() ;

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

#endif // MY_HEADER_H

Ou il pourrait être inclus indirectement par l'en-tête .hpp correspondant en le joignant à la extern "C"déclaration.

Par exemple:

#ifndef MY_HEADER_HPP
#define MY_HEADER_HPP

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

#endif // MY_HEADER_HPP

et:

#ifndef MY_HEADER_H
#define MY_HEADER_H

void myCFunction() ;

#endif // MY_HEADER_H

J'ai toujours considéré l'en- .hpptête comme une sorte de valise .het de .cppfichiers ... un en-tête qui contient également des détails d'implémentation.

Généralement, lorsque j'ai vu (et utilisé) .hppune extension, il n'y a pas de .cppfichier correspondant . Comme d'autres l'ont dit, ce n'est pas une règle stricte et rapide, juste comment j'ai tendance à utiliser des .hppfichiers.

Peu importe quelle extension vous utilisez. L'un ou l'autre est OK.

J'utilise *.hpour C et *.hpppour C ++.

EDIT [Ajout d'une suggestion de Dan Nissenbaum]:

Par une convention, les fichiers .hpp sont utilisés lorsque les prototypes sont définis dans l'en-tête lui-même. De telles définitions dans les en-têtes sont utiles dans le cas des modèles, car le compilateur génère le code pour chaque type uniquement lors de l'instanciation du modèle. Par conséquent, s'ils ne sont pas définis dans les fichiers d'en-tête, leurs définitions ne seront pas résolues au moment de la liaison à partir d'autres unités de compilation. Si votre projet est un projet C ++ uniquement qui fait un usage intensif des modèles, cette convention sera utile.

Certaines bibliothèques de modèles qui adhèrent à cette convention fournissent des en-têtes avec des extensions .hpp pour indiquer qu'elles n'ont pas de fichiers .cpp correspondants.

une autre convention consiste à utiliser .h pour les en-têtes C et .hpp pour C ++; un bon exemple serait la bibliothèque boost.

Citation de la FAQ Boost,

Les extensions de fichier communiquent le "type" du fichier, à la fois aux humains et aux programmes informatiques. L'extension «.h» est utilisée pour les fichiers d'en-tête C et communique donc la mauvaise chose à propos des fichiers d'en-tête C ++. L'utilisation d'aucune extension ne communique rien et force l'inspection du contenu du fichier pour déterminer le type. L'utilisation de '.hpp' l'identifie sans ambiguïté comme fichier d'en-tête C ++ et fonctionne bien dans la pratique. (Rainer Deyke)

J'ai récemment commencé à utiliser *.hpppour les en-têtes c ++.

La raison en est que j'utilise emacs comme mon éditeur principal et qu'il passe automatiquement en mode c lorsque vous chargez un *.hfichier et en mode c ++ - lorsque vous chargez un *.hppfichier.

Outre ce fait , je ne vois pas de bonnes raisons de choisir *.hplus *.hppou vice-versa.

Je réponds à ceci comme rappel, pour donner le point à mon commentaire (s) sur la réponse "user1949346" à ce même OP.

Donc, comme beaucoup l'ont déjà répondu: dans les deux cas, c'est bien. Suivi par met l'accent sur leurs propres impressions.

Introduction, comme dans les commentaires précédents, je C++pense que les extensions d'en-tête sont proposées .hs'il n'y a en fait aucune raison de s'y opposer.

Étant donné que les documents ISO / CEI utilisent cette notation des fichiers d'en-tête et aucune correspondance de chaîne .hppne se produit même dans leurs documentations linguistiques C++.

Mais je vise maintenant pour une raison acceptable POURQUOI l'un ou l'autre est correct, et surtout pourquoi il n'est pas sujet à la langue elle-même.

Alors c'est parti.

La C++documentation (je prends en fait référence à la version N3690) définit qu'un en-tête doit se conformer à la syntaxe suivante:

2.9 Noms d'en-tête

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 "

Donc, comme nous pouvons l'extraire de cette partie, le nom du fichier d'en-tête peut également être tout ce qui est valide dans le code source. Sauf '\n's'il contient des caractères et selon qu'il doit être inclus, <>il n'est pas autorisé à contenir a >. Ou, dans le cas ""contraire, s'il est inclus par -include, il n'est pas autorisé à contenir a ".

En d'autres termes: si vous aviez un environnement supportant les noms de fichiers comme prettyStupidIdea.>, un include comme:

#include "prettyStupidIdea.>"

serait valide, mais:

#include <prettyStupidIdea.>>

serait invalide. L'inverse est le même.

Et même

#include <<.<>

serait un nom de fichier d'en-tête inclus valide.

Même ce serait conforme C++, ce serait une idée assez stupide, tho.

Et c'est pourquoi .hppest également valable.

Mais ce n'est pas le résultat des décisions des comités sur la langue!

Donc, discuter de l'utilisation .hppest la même chose que de le faire .cc, .mmou de tout ce que j'ai lu dans d'autres articles sur ce sujet.

Je dois admettre que je ne sais pas d'où .hppvient ¹ , mais je parierais qu'un inventeur d'un outil d'analyse, IDE ou autre chose concerné C++est venu à cette idée pour optimiser certains processus internes ou simplement pour en inventer (probablement même pour eux nécessairement ) nouvelles conventions de dénomination.

Mais cela ne fait pas partie de la langue.

Et chaque fois que l'on décide de l'utiliser de cette façon. Que ce soit parce qu'il aime le plus ou parce que certaines applications du flux de travail l' exigent, il n'a jamais ² est une exigence de la langue. Donc, celui qui dit "le pp est parce qu'il est utilisé avec C ++", se trompe simplement en ce qui concerne la définition des langages.

C ++ permet tout ce qui respecte le paragraphe précédent. Et s'il y a quelque chose que le comité a proposé d'utiliser, alors il l'utilise .hpuisque c'est l'extension poursuivie dans tous les exemples du document ISO.

Conclusion:

Tant que vous ne voyez / ressentez aucun besoin d'utiliser .hplus .hppou vice versa, vous ne devriez pas vous embêter. Parce que les deux formeraient un nom d'en-tête valide de même qualité par rapport à la norme. Et donc tout ce qui vous oblige à utiliser .hou .hppconstitue une restriction supplémentaire de la norme qui pourrait même être en contradiction avec d'autres restrictions supplémentaires non conformes les unes aux autres. Mais comme OP ne mentionne aucune restriction de langue supplémentaire, c'est la seule réponse correcte et approuvable à la question

" * .h ou * .hpp pour vos définitions de classe " est:

Les deux sont également corrects et applicables tant qu'aucune restriction externe n'est présente.

¹ _{D'après ce que je sais, c'est apparemment le cadre de boost qui est venu avec cette .hppextension.}

² _{Bien sûr, je ne peux pas dire ce que certaines versions futures apporteront!}

Je préfère .hpp pour C ++ pour faire comprendre aux éditeurs et aux autres programmeurs qu'il s'agit d'un en-tête C ++ plutôt que d'un fichier d'en-tête C.

C ++ ("C Plus Plus") a du sens en tant que .cpp

Avoir des fichiers d'en-tête avec une extension .hpp n'a pas le même flux logique.

Vous pouvez appeler vos inclus comme bon vous semble.

Il suffit de spécifier ce nom complet dans le #include.

Je suggère que si vous travaillez avec C à utiliser .het quand avec C ++ à utiliser .hpp.

Ce n'est finalement qu'une convention.

Codegear C ++ Builder utilise .hpp pour les fichiers d'en-tête générés automatiquement par les fichiers source Delphi et les fichiers .h pour vos "propres" fichiers d'en-tête.

Ainsi, lorsque j'écris un fichier d'en-tête C ++, j'utilise toujours .h.

Dans l'un de mes emplois au début des années 90, nous avons utilisé respectivement .cc et .hh pour les fichiers source et d'en-tête. Je le préfère toujours à toutes les alternatives, probablement parce qu'il est plus facile à taper.

Bjarne Stroustrup et Herb Sutter ont une déclaration à cette question dans leurs directives C ++ Core trouvées sur: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#S-source qui fait également référence aux derniers changements dans l'extension standard (C ++ 11, C ++ 14, etc.)

SF.1: Utilisez un suffixe .cpp pour les fichiers de code et .h pour les fichiers d'interface si votre projet Y ne respecte pas déjà une autre convention

C'est une convention de longue date. Mais la cohérence est plus importante, donc si votre projet utilise autre chose, suivez-le. Remarque

Cette convention reflète un modèle d'utilisation courant: les en-têtes sont plus souvent partagés avec C pour être compilés à la fois en C ++ et C, qui utilise généralement .h, et il est plus facile de nommer tous les en-têtes .h au lieu d'avoir des extensions différentes uniquement pour les en-têtes qui sont destinés à partager avec C. D'autre part, les fichiers d'implémentation sont rarement partagés avec C et doivent donc être distingués des fichiers .c, il est donc préférable de nommer tous les fichiers d'implémentation C ++ autrement (comme .cpp).

Les noms spécifiques .h et .cpp ne sont pas requis (simplement recommandés par défaut) et d'autres noms sont largement utilisés. Les exemples sont .hh, .C et .cxx. Utilisez de tels noms de manière équivalente. Dans ce document, nous faisons référence à .h et .cpp> comme raccourci pour les fichiers d'en-tête et d'implémentation, même si l'extension réelle peut être différente.

Votre IDE (si vous en utilisez un) peut avoir des opinions bien arrêtées sur les suffisances.

Je ne suis pas un grand fan de cette convention car si vous utilisez une bibliothèque populaire comme boost, votre cohérence est déjà rompue et vous devriez mieux utiliser .hpp.

Comme beaucoup ici l'ont déjà mentionné, je préfère également utiliser .hpp pour les bibliothèques uniquement en-tête qui utilisent des classes / fonctions de modèle. Je préfère utiliser .h pour les fichiers d'en-tête accompagnés de fichiers source .cpp ou de bibliothèques partagées ou statiques.

La plupart des bibliothèques que je développe sont basées sur des modèles et doivent donc être uniquement en-tête, mais lors de l'écriture d'applications, j'ai tendance à séparer la déclaration de l'implémentation et à me retrouver avec des fichiers .h et .cpp

Heureusement, c'est simple.

Vous devez utiliser l'extension .hpp si vous travaillez avec C ++ et vous devez utiliser .h pour C ou mélanger C et C ++.

J'utilise .h parce que c'est ce que Microsoft utilise et ce que crée son générateur de code. Pas besoin d'aller à contre-courant.

Dans "The C ++ Programming Language, Third Edition by Bjarne Stroustrup", le n ° 1 livre C ++ à lire absolument, il utilise * .h. Je suppose donc que la meilleure pratique consiste à utiliser * .h.

Cependant, * .hpp est bien aussi!

Il est facile pour les outils et les humains de différencier quelque chose . C'est ça.

En utilisation conventionnelle (par boost, etc.), il .hpps'agit spécifiquement des en-têtes C ++. D'un autre côté, .hconcerne les en-têtes non C ++ uniquement (principalement C). Il est généralement difficile de détecter précisément la langue du contenu, car il existe de nombreux cas non triviaux, de sorte que cette différence rend souvent un outil prêt à l'emploi facile à écrire. Pour les humains, une fois la convention obtenue, elle est également facile à retenir et à utiliser.

Cependant, je voudrais souligner que la convention elle-même ne fonctionne pas toujours, comme prévu.

• Il n'est pas forcé par la spécification des langages , ni C ni C ++. Il existe de nombreux projets qui ne suivent pas la convention. Une fois que vous devez les fusionner (les mélanger), cela peut être gênant.
• .hpplui-même n'est pas le seul choix. Pourquoi pas .hhou .hxx? (Quoi qu'il en soit, vous avez généralement besoin d'au moins une règle conventionnelle concernant les noms de fichiers et les chemins d'accès.)

J'utilise personnellement les deux .het .hppdans mes projets C ++. Je ne respecte pas la convention ci-dessus car:

• Les langues utilisées par chaque partie des projets sont explicitement documentées. Aucune chance de mélanger C et C ++ dans le même module (répertoire). Chaque bibliothèque tierce doit se conformer à cette règle.
• Les spécifications linguistiques conformes et les dialectes linguistiques autorisés utilisés par les projets sont également documentés. (En fait, je documente même la source des fonctionnalités standard et la correction de bogue (sur la norme de langue) utilisée .) C'est un peu plus important que de distinguer les langues utilisées car elles sont trop sujettes aux erreurs et au coût du test (par exemple compatibilité du compilateur) peut être important (compliqué et long), en particulier dans un projet qui est déjà en C ++ presque pur . Les noms de fichiers sont trop faibles pour gérer cela.
• Même pour le même dialecte C ++, il peut y avoir des propriétés plus importantes adaptées à la différence. Par exemple, voir la convention ci-dessous.
• Les noms de fichiers sont essentiellement des morceaux de métadonnées fragiles. La violation de la convention n'est pas si facile à détecter. Pour être stable dans le traitement du contenu, un outil ne devrait finalement pas seulement dépendre des noms. La différence entre les extensions n'est qu'un indice. Les outils qui l'utilisent ne devraient pas non plus se comporter de la même manière tout le temps, par exemple la détection de la langue des .hfichiers sur github.com. (Il peut y avoir quelque chose dans les commentaires comme shebang pour que ces fichiers source soient de meilleures métadonnées, mais ce n'est même pas conventionnel comme les noms de fichiers, donc pas fiable en général.)

J'utilise habituellement .hppsur les en-têtes C ++ et les en-têtes doivent être utilisés (maintenus) dans un manière uniquement en-tête , par exemple comme bibliothèques de modèles. Pour les autres en-têtes de .h, il existe soit un .cppfichier correspondant comme implémentation, soit un en-tête non C ++. Ce dernier est trivial pour se différencier à travers le contenu de l'en-tête par les humains (ou par des outils avec des métadonnées intégrées explicites, si nécessaire).

L'extension du fichier source peut avoir un sens pour votre système de construction, par exemple, vous pouvez avoir une règle dans votre makefile pour .cppou .cfichiers, ou votre compilateur (par exemple Microsoftcl.exe ) peut compiler le fichier en C ou C ++ en fonction de l'extension.

Étant donné que vous devez fournir le nom de fichier entier à la #includedirective, l'extension de fichier d'en-tête n'est pas pertinente. Vous pouvez inclure un .cfichier dans un autre fichier source si vous le souhaitez, car il s'agit simplement d'une inclusion textuelle. Votre compilateur peut avoir une option pour vider la sortie prétraitée qui le rendra clair (Microsoft: /Ppour prétraiter dans un fichier, /Epour prétraiter stdout, /EPpour omettre des #linedirectives, /Cpour conserver des commentaires)

Vous pouvez choisir d'utiliser .hppdes fichiers qui ne concernent que l'environnement C ++, c'est-à-dire qu'ils utilisent des fonctionnalités qui ne se compileront pas en C.

Il n'y a aucun avantage à une extension particulière, à part que celle-ci peut avoir une signification différente pour vous, le compilateur et / ou vos outils. header.hest un en-tête valide. header.hppest un en-tête valide. header.hhest un en-tête valide. header.hxest un en-tête valide. h.headerest un en-tête valide. this.is.not.a.valid.headerest un en-tête valide en déni. ihjkflajfajfklafest un en-tête valide. Tant que le nom peut être analysé correctement par le compilateur et que le système de fichiers le prend en charge, c'est un en-tête valide, et le seul avantage de son extension est ce que l'on y lit.

Cela étant dit, être capable de faire des hypothèses précises sur la base de l'extension est très utile, il serait donc judicieux d'utiliser un ensemble de règles facilement compréhensible pour vos fichiers d'en-tête. Personnellement, je préfère faire quelque chose comme ça:

1. S'il existe déjà des directives établies, suivez-les pour éviter toute confusion.
2. Si tous les fichiers source du projet sont pour la même langue, utilisez .h. Il n'y a aucune ambiguïté.
3. Si certains en-têtes sont compatibles avec plusieurs langues, tandis que d'autres ne sont compatibles qu'avec une seule langue, les extensions sont basées sur la langue la plus restrictive avec laquelle un en-tête est compatible. Un en-tête compatible avec C, ou avec les deux C et C ++, obtient .h, tandis qu'un en-tête compatible avec C ++ mais pas C obtient .hppou .hhou quelque chose du genre.

Bien sûr, cela n'est qu'une des nombreuses façons de gérer les extensions, et vous ne pouvez pas nécessairement faire confiance à votre première impression même si les choses semblent simples. Par exemple, j'ai vu la mention de l'utilisation .hpour les en-têtes normaux et .tpppour les en-têtes qui ne contiennent que des définitions pour les fonctions membres de classe de modèle, avec des .hfichiers qui définissent les classes de modèle, y compris les .tppfichiers qui définissent leurs fonctions membres (au lieu de l'en- .htête contenant directement à la fois le déclaration de fonction et définition). Pour un autre exemple, bon nombre de personnes reflètent toujours le langage de l'en-tête dans son extension, même lorsqu'il n'y a aucune chance d'ambiguïté; pour eux, .hest toujours un en-tête C et .hpp(ou .hh, ou.hxx, etc.) est toujours un en-tête C ++. Et encore une fois, certaines personnes utilisent .hpour "en-tête associé à un fichier source" et .hpppour "en-tête avec toutes les fonctions définies en ligne".

Compte tenu de cela, le principal avantage serait de nommer systématiquement vos en-têtes dans le même style et de rendre ce style facilement visible pour quiconque examine votre code. De cette façon, toute personne familière avec votre style de codage habituel sera en mesure de déterminer ce que vous voulez dire avec une extension donnée en un coup d'œil.