C ++: Raison pour laquelle utiliser ".hh" comme extension pour les fichiers d'en-tête C ++
Je voudrais savoir pourquoi nous utilisons ".hh" comme extension pour les fichiers d'en-tête C++ au lieu d'utiliser simplement ".h".
Les fichiers d'en-tête sont prétraités et le préprocesseur ne se soucie même pas de l'extension du fichier d'en-tête. Donc, même si je crée un fichier d'en-tête avec une extension ".qwe" (test.qwe). Ensuite, pourquoi utiliser ".hh" comme extension pour les fichiers d'en-tête C++.
Certains disent que nous utilisons ".cc" comme extension pour les fichiers C++ pour se différencier des fichiers C (qui a une extension ".c"), de même que nous utilisons en utilisant ".hh" comme extension pour les fichiers d'en-tête C++ pour se différencier de C fichiers d'en-tête (qui ont une extension ".h"). Je ne pense pas que ce soit une raison valable.
Est-ce que quelqu'un connaît la raison du nom de cette manière?
Certains disent que nous utilisons ".cc" comme extension pour les fichiers C++ pour se différencier des fichiers C (qui a une extension ".c"), de même nous utilisons en utilisant ".hh" comme extension pour les fichiers d'en-tête C++ pour différencier des fichiers d'en-tête C (qui a une extension ".h").
C’est exactement la raison. C'est juste pour différencier les en-têtes CPP des en-têtes C.
Certains programmeurs et bibliothèques, tels que Boost, utilisent .hpp pour les en-têtes CPP. Mon choix personnel est le suivant:
- exemple.c
- example.cpp
- exemple.h
- exemple.h ++
Même s'ils appartiennent tous à un énorme projet, vous pouvez toujours déterminer lequel est lequel. Aucune description n'est nécessaire.
Vous pouvez nommer vos en-têtes comme vous le souhaitez, ils ne peuvent même pas avoir d'extension du tout.
Cette FAQ mentionne les conventions d'appellation des en-têtes.
Ce n'est pas pour une raison spécifique, c'est juste une convention (spécifique au développeur ou au projet). Comme "extension de fichier" n'est qu'une partie du nom, cela n'a pas beaucoup d'importance, car les fichiers source ne sont que des fichiers texte. De plus, les fichiers d'en-tête sont simplement copiés-collés dans le fichier qui les incluait (via #include, donc l'extension de fichier signifie encore moins pour eux.
Les en-têtes des bibliothèques de Borland avaient .hpp extension. Les en-têtes de bibliothèque standard de C++ n'ont aucune extension. C'est juste une question de convention et de goût personnel.
C'est complètement conventionnel, il n'y a pas de raison particulière pour cela. Habituellement, les gens essaient de rester cohérents à travers un projet, ou à travers des équipes ou même une entreprise entière. Il aide les développeurs qui récupèrent votre code après votre absence depuis longtemps à comprendre que abc.hh va avec le fichier abc.cc et abc.h va avec abc.c.
Une raison, si je crée une DLL qui a une API C autour d'un tas de code C++, je dois faire la différence entre mes en-têtes C que le client peut utiliser pour importer des fonctions C et mes en-têtes C++ internes que je n'ai pas explicitement souhaitez autoriser le client à importer.
La liaison à une fonction C est assez simple à partir de la plupart des langages/environnements avec presque pas de surcharge. Vous n'avez pas à penser à toutes les complexités héritées en C++. Donc, si je devais travailler avec une telle bibliothèque, je serais sûr de séparer mon C++ de mon interface C.
Je pense que c'est surtout une convention sociale.
Cependant, les compilateurs GCC récents sont capables de compiler un (unique) en-tête foo.hh ou foo.h en quelque chose comme foo.hh.gch ou foo.h.gch qui contient essentiellement une image de segment de mémoire persistante du compilateur (le cc1plus programme démarré par g++) après avoir analysé cet en-tête.
Notez que la bibliothèque standard C++ 11 définit des fichiers d'en-tête comme par ex. <vector> sans aucune extension.