Extension de fichier de code C ++? .cc vs .cpp [fermé]

J'ai vu du code C ++ enregistré sous forme de fichiers .ccet .cpp. Y a-t-il une différence entre les deux?

Le guide de style Google semble suggérer .cc, mais ne fournit aucune explication.

Je m'intéresse principalement aux programmes sur les systèmes Linux.

En fin de compte, cela n'a pas d'importance car les compilateurs C ++ peuvent traiter les fichiers dans l'un ou l'autre format. Si c'est un vrai problème au sein de votre équipe, lancez une pièce et passez au travail réel.

GNU GCC reconnaît tous les éléments suivants sous forme de fichiers C ++, et utilisera C ++ compilation peu importe si vous l' invoquons par gcc ou g ++: .C, .cc, .cpp, .CPP, .c++, .cpou .cxx.

Notez que .C- le cas est important dans GCC, .cc'est un fichier C alors que .Cc'est un fichier C ++ (si vous laissez le compilateur décider de ce qu'il compile).

GCC prend également en charge d'autres suffixes pour indiquer une gestion spéciale, par exemple un .iifichier sera compilé en C ++, mais pas prétraité (destiné au code prétraité séparément). Tous les suffixes reconnus sont détaillés sur gcc.gnu.org

De bons conseils sur l'utilisation du makefile et d'autres outils, en tenant compte des outils non compilateurs tout en décidant quelle extension utiliser est une excellente approche pour aider à trouver une réponse qui vous convient.

Je voulais juste ajouter ce qui suit pour aider avec certaines informations .ccvs .cppque j'ai trouvées. Les extensions suivantes sont décomposées par différents environnements (du livre "C ++ Primer Plus"):

Utilisations Unix: .C, .cc, .cxx,.c

GNU C ++ utilise: .C, .cc, .cxx, .cpp,.c++

Mars: utilisations numériques .cpp,.cxx

Borland C ++ utilise: .cpp

Watcom utilise: .cpp

Microsoft Visual C ++ utilise: .cpp, .cxx,.cc

Utilisations: CodeWarrior Metrowerks .cpp, .cp, .cc, .cxx,.c++

Les différents environnements prennent en charge différentes extensions. Moi aussi, je cherchais à répondre à cette question et j'ai trouvé ce message. Sur la base de ce post, je pense que je pourrais aller avec .hppet .cpppour faciliter la reconnaissance multi-plateforme / multi-outil.

.cppest l'extension recommandée pour C ++ pour autant que je sache. Certaines personnes recommandent même d'utiliser .hpppour les en-têtes C ++, juste pour faire la différence avec C.

Bien que le compilateur ne se soucie pas de ce que vous faites, c'est une préférence personnelle.

J'utilise personnellement l' .ccextension pour les fichiers d'implémentation, les .hhen-têtes et .inlles modèles en ligne /.

Comme dit précédemment, c'est avant tout une question de goût.

D'après ce que j'ai vu , .ccsemble être plus " orienté vers les projets open source ", comme il est conseillé dans certains grands styles de codage de logiciels open source, alors que. cppsemble être plus Windowish.

--- ÉDITER

Comme mentionné, c'est "d'après ce que j'ai vu" , cela peut être faux. C'est juste que tous les projets Windows sur lesquels j'ai travaillé sont utilisés .cpp, et beaucoup de projets open source (qui sont principalement sur des likes Unix) .cc.

Exemples de styles de codage utilisant .cc:

• Google: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
• ICL: http://www.doc.ic.ac.uk/lab/cplus/c++.rules/chap4.html#sect2

Les autres extensions de fichier utilisées incluent .cxxet .C(C majuscule). Je crois que Bjarne Stroustrup a utilisé à l' .Corigine. .cppest le nom du préprocesseur C, il est donc regrettable qu'il ait également été utilisé pour C ++.

L'autre option est .cxxoù le xest censé être un plus tourné de 45 °.

Windows, Mac et Linux prennent tous en charge .c++, nous devons donc simplement l'utiliser.

Plusieurs personnes disent que .cccela ne représente rien? C'est possible. C ++ a commencé sa vie en tant que "C avec classes".

C'est vrai .ccet ce .cppsont aussi des noms de commandes sur la plupart des systèmes Unix (compilateur c et préprocesseur c respectivement).

J'utilise .cppexclusivement, mais j'ai commencé sur Windows. .ccest plus une convention Unix, même si je la vois de moins en moins. La marque GNU a des règles .cppdonc c'est probablement préférable, cela fonctionnera par défaut sur Windows et tout le reste. D'un autre côté, le C ++ moderne n'utilise aucune extension pour les en-têtes, je n'aime vraiment pas ça. Tous mes projets utilisent .hdes fichiers d'en-tête, et ils prennent en charge autant que possible C et C ++ via extern "C"et les tests __cplusplus.

Suivez simplement la convention utilisée par le projet / l'équipe.

Personnellement, je n'ai jamais vu .ccde projet sur lequel j'ai travaillé, mais en toute technicité, le compilateur s'en fiche.

Qui se souciera des développeurs travaillant sur votre source, donc ma règle de base est d'aller avec ce que votre équipe est à l'aise. Si votre «équipe» est la communauté open source, optez pour quelque chose de très courant, qui .cppsemble être le favori.

Comme avec la plupart des conventions de style, il n'y a que deux choses qui comptent:

1. Soyez cohérent dans ce que vous utilisez, dans la mesure du possible.
2. Ne concevez rien qui dépend d'un choix spécifique utilisé.

Ceux-ci peuvent sembler contradictoires, mais ils ont chacun une valeur pour leurs propres raisons.

.Cet .ccsemblent être la norme pour les (quelques) programmes C ++ orientés Unix que j'ai vus. Je me suis toujours utilisé .cpp, car je ne travaille vraiment que sur Windows et c'est la norme depuis toujours.

Je le recommande .cpppersonnellement, car ... cela signifie "C Plus Plus". Il est bien sûr extrêmement important que les extensions de fichier soient des acronymes, mais si cette justification s'avère insuffisamment convaincante, d'autres éléments importants sont la non-utilisation de la touche Maj (qui exclut .Cet .c++) et l'évitement des métacaractères d'expression régulière lorsque cela est possible (qui exclut .c++- malheureusement, vous ne pouvez pas vraiment éviter cela .bien sûr.).

Cela n'exclut pas .cc, donc même s'il ne représente vraiment rien (ou le fait-il?), C'est probablement un bon choix pour le code orienté Linux.

J'ai utilisé .C et .h pour la source et l'en-tête, respectivement. Une bonne chose avec ce choix est que, sur la ligne de commande, il est facile à utiliser *.[Ch]pour sélectionner tous les fichiers de code. L'utilisation .Cpourrait être un problème sur les systèmes de fichiers insensibles à la casse, mais si vous en avez foo.cet foo.Cdans le même répertoire, vous méritez tout de même ce que vous obtenez :)

L'extension .cc est nécessaire pour utiliser des règles implicites dans les makefiles. Parcourez ces liens pour mieux comprendre les makefiles, mais regardez principalement le second, car il indique clairement l'utilité de l'extension .cc:

ftp://ftp.gnu.org/old-gnu/Manuals/make-3.79.1/html_chapter/make_2.html

https://ftp.gnu.org/old-gnu/Manuals/make-3.79.1/html_chapter/make_10.html

Je viens d'apprendre cela maintenant.

Peu importe laquelle de ces extensions vous utiliseriez. Choisissez ce que vous aimez le plus, soyez juste cohérent avec la dénomination. La seule exception que je connaisse avec cette convention de dénomination est que je ne pouvais pas faire WinDDK(ou est-ce WDKmaintenant?) Pour compiler des .ccfichiers. Sur Linux, ce n'est guère un problème.

Je démarre un nouveau projet C ++ et j'ai commencé à chercher les dernières nouveautés dans le style C ++. Je me suis retrouvé ici en ce qui concerne la dénomination des fichiers et j'ai pensé que je partagerais comment j'ai fait mon choix. Voici:

Stroustrup considère cela plus comme une considération commerciale que technique .

En suivant ses conseils, vérifions ce que les chaînes d'outils attendent.

Pour UNIX / Linux, vous pouvez interpréter les règles de création GNU par défaut suivantes comme favorisant le suffixe du nom de fichier .cc, car les règles .cpp et .C ne sont que des alias:

$ make -p | egrep COMPILE[^=]+=
COMPILE.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c
COMPILE.cpp = $(COMPILE.cc)
COMPILE.C = $(COMPILE.cc)

(Remarque: il n'y a pas d'alias COMPILE.cxx par défaut)

Donc, si vous ciblez UNIX / Linux, .cc et .cpp sont de très bonnes options.

Lorsque vous ciblez Windows, vous recherchez des problèmes avec .C, car son système de fichiers est insensible à la casse. Et il peut être important pour vous de noter que Visual Studio favorise le suffixe .cpp

Lorsque vous ciblez macOS, notez que Xcode préfère .cpp / .hpp (juste vérifié sur Xcode 10.1). Vous pouvez toujours modifier le modèle d'en-tête pour utiliser .h.

Pour ce que cela vaut, vous pouvez également baser votre décision sur les bases de code que vous aimez. Google utilise .cc et LLVM libc ++ utilise .cpp, par exemple.

Qu'en est-il des fichiers d'en-tête? Ils sont compilés dans le contexte d'un fichier C ou C ++, il n'y a donc pas besoin de compilateur ou de système de génération pour distinguer .h de .hpp. La mise en évidence de la syntaxe et l'indentation automatique par votre éditeur / IDE peuvent cependant être un problème, mais cela est résolu en associant tous les fichiers .h à un mode C ++. À titre d'exemple, ma configuration emacs sous Linux charge tous les fichiers .h en mode C ++ et modifie très bien les en-têtes C. Au-delà de cela, lorsque vous mélangez C et C ++, vous pouvez suivre ces conseils .

Ma conclusion personnelle : .cpp / .h est le chemin de moindre résistance.

Comme d'autres l'ont écrit avant moi, à la fin c'est ce qui est utilisé par votre projet / équipe / entreprise.

Personnellement, je n'utilise pas d' ccextension, j'essaie de réduire le nombre d'extensions et de ne pas les augmenter, sauf s'il y a une valeur claire (à mon avis).

Pour ce que ça vaut, voici ce que j'utilise :

c - Code C pur uniquement, pas de classes ou de structures avec des méthodes.

cpp - Code C ++

hpp- Code en-têtes uniquement. Les implémentations sont dans les en-têtes (comme les classes de modèles)

h- fichiers d'en-tête pour C / C ++. Je suis d'accord qu'une autre distinction peut être faite, mais comme je l'ai écrit, j'essaie de réduire le nombre d'extensions pour plus de simplicité. Au moins pour les projets C ++ dans lesquels j'ai travaillé, les hfichiers pour pure-C sont plus rares, donc je ne voulais pas ajouter une autre extension.