quelle est la différence entre php et hxx?

pour gcc ils devraient être les mêmes, non? lequel est le plus populaire , je suis en train de préparer un projet à partir de zéro et je tiens à en choisir un parmi ces 2.

grâce

Voir: stackoverflow.com/questions/152555/...

OriginalL'auteur James Bond | 2009-12-07

  1. 19

    En C++, l'extension du fichier n'est pas réellement question. L'utilisation de .h, .hpp, .hxx, ou pas de l'extension de fichier sont par convention.

    De la bibliothèque standard utilise pas d'extension de fichier pour ses fichiers d'en-tête. De nombreux projets, y compris les Stimuler, de les utiliser .hpp. Le nombre de projets .h. Il suffit de choisir un et d'être cohérent dans votre projet.

    Un problème que j'ai pu croiser .h extensions en C++, en-têtes, c'est que certains éditeurs pensent qu'ils sont C, puis vous obtenez beaucoup de laide de la syntaxe des problèmes dès qu'il y a un "espace de noms" ou de "classe" ou de quelque chose.
    Voir, par exemple, ma question: stackoverflow.com/questions/226402/...

    OriginalL'auteur James McNellis

  2. 4

    Le compilateur ne fait pas la distinction entre les deux extensions, donc, techniquement, il n'est pas question que celle que vous utilisez. Personnellement, j'utilise l' .hxx extension pour les fichiers d'en-tête qui sont uniquement utilisées en interne par le projet, et .php pour ceux qui devraient être communiqué à la bibliothèque/le logiciel.

    OriginalL'auteur Dragonion

  3. 2

    Je propose que nous nous ré-ouvrir ce débat, dans la perspective d'une découverte récente que j'ai fait. Pour les 9 dernières années, j'ai utilisé les suivants convention de nommage pour les fichiers source dans mon C et C++ projets.

    • C = Droite code source C, contenant un ou plusieurs points d'entrée
    • RPC = C++ source code, contenant un ou plusieurs points d'entrée
    • H = Déclaration des fonctions, macros, les structures, les typedefs, etc.
    • INL = Inline (corps de fonction) que sont les corps de deux ou plusieurs fonctions dont le principal fichier de définition est un C ou un fichier CPP, dans laquelle elles sont incorporées par #include

    Un exemple de ces corps de fonction, MyStringFunctionA, la norme ANSI mise en œuvre, est définie dans l'MyStringFunctionA.cpp tandis que MyStringFunctionW, l'Unicode (caractères larges) la mise en œuvre, est définie dans l'MyStringFunctionW.cpp. MyStringFunctionA.cpp et MyStringFunctionW.cpp contient le prototype, l'ouverture et la fermeture des crochets, et les en-têtes, sous réserve de l'UNICODE pour les caractères larges de la version. Le corps de la fonction est définie dans le fichier INI, qui est inclus à la volée, dans la définition de la fonction bloc.

    Combiné avec des génériques de TCHAR mappages, cette approche simplifie grandement le maintien de l'Unicode et ANSI versions, qui demeurent en activité.

    Cette convention de nommage a travaillé beaucoup avec Visual Studio 6. Cependant, quand j'ai commencé à migrer ma base de code de Visual Studio 2013, j'ai découvert un ennuyeux changement qui était à l'origine de la confusion. Bien que tout compilé proprement, quand un de mes INL fichiers est ouvert dans l'éditeur de code, je vois des dizaines de Intellisense "erreurs" figurant dans la fenêtre des Erreurs. J'ai cité le terme "erreurs" parce qu'ils ne sont pas de vraies erreurs; ils disparaissent lors de l'INL fichier est fermé, et les C et les fichiers CPP dans lequel l'iNL est tiré de la compilation sans erreur, le lien, et de l'exécuter correctement.

    OriginalL'auteur David A. Gray

  4. 0

    En-tête des extensions de fichier n'avez pas l'habitude de faire une différence, mais je sais que, dans certains cas, l'extension de l' .fichier cpp peut faire une différence. En fonction de votre compilateur le front-end peut choisir de compiler le fichier source comme C ou C++.

    Cela peut faire une différence, surtout si vous combinez la compilation avec la phase de liaison, car elle peut conduire à différentes bibliothèques être lié (par exemple, g++ vs gcc) et de sorte que vous pouvez contrôler le résultat dans votre makefile.

    OriginalL'auteur Robert Tuck