Code C++ dans les fichiers d’en-tête

Question

Mon style personnel avec le C++ a toujours déclarations de classe dans un fichier include, et de définitions dans un .fichier cpp, comme stipulé dans Loki, en réponse aux Fichiers d'en-Tête C++, le Code de la Séparation. Certes, une partie de la raison pour laquelle j'aime ce style qui a probablement à voir avec toutes les années que j'ai passé de codage Modula-2 et Ada, qui ont tous deux un régime similaire à la spécification des fichiers et des corps de fichiers.

J'ai un collègue de travail, beaucoup plus de connaissance en C++ que j'ai, qui est en insistant sur le fait que tous les C++ déclarations devraient, si possible, inclure les définitions dans le fichier d'en-tête. Il ne dit pas: c'est une valable alternative de style, ou même un peu plus de style, mais c'est la nouvelle universellement acceptée de style que tout le monde est maintenant à l'aide de C++.

Je ne suis pas aussi souple comme j'ai l'habitude d'être, donc je ne suis pas vraiment hâte de scrabble sur ce train en marche de son jusqu'à ce que je vois d'un peu plus de gens là-haut avec lui. Alors, quelle est la fréquence de cet idiome vraiment?

Juste pour donner de la structure à l'réponses: Est-il maintenant de La Façon, très commune, peu commune, rare, ou un bug-out fou?

Answer 1

Votre collègue qui est mal, de la façon la plus courante est et a toujours été de placer du code dans .fichiers cpp (ou quelle que soit l'extension que vous souhaitez) et les déclarations dans les en-têtes.

Il y a parfois le mérite de mettre le code dans l'en-tête, cela peut permettre de plus intelligent inline par le compilateur. Mais dans le même temps, il peut détruire votre temps de compilation puisque tout le code doit être traité à chaque fois qu'il est compris par le compilateur.

Enfin, il est impossible circulaire pour des relations d'objet (parfois souhaité) lorsque tous les code les en-têtes.

Ligne de fond, vous avez eu raison, il a tort.

EDIT: j'ai pensé à votre question. Il y a un cas où ce qu'il dit est vrai. modèles. Beaucoup de nouveaux "moderne" des bibliothèques telles que coup de pouce de faire un usage intensif des modèles et sont souvent "en-tête uniquement." Toutefois, cela ne devrait être fait lorsque vous traitez avec des modèles comme c'est le seul moyen de le faire lorsque vous traitez avec eux.

EDIT: Certaines personnes souhaiteraient un peu plus de précisions, voici quelques réflexions sur les inconvénients de l'écriture de "l'en-tête uniquement" code:

Si vous recherchez autour de vous, vous verrez beaucoup de gens qui essaient de trouver un moyen de réduire les temps de compilation lorsque vous traitez avec des boost. Par exemple: Comment réduire les temps de compilation avec Boost Asio, qui est de voir un 14s de la compilation d'un seul 1K fichier avec boost inclus. 14s peut sembler ne pas être "explosion", mais il est certainement beaucoup plus que ce qui est typique et peut ajouter assez rapidement. Lorsque vous traitez avec un grand projet. L'en-tête uniquement bibliothèques en effet les temps de compilation dans un tout à fait mesurable. Nous venons de le tolérer parce que boost est donc utile.

En outre, il ya beaucoup de choses qui ne peut pas être fait dans les en-têtes (même boost fournit des bibliothèques vous devez le lier à certains éléments tels que les threads, système de fichiers, etc). Un exemple Principal est que vous ne pouvez pas avoir de simples objets globaux dans l'en-tête uniquement libs (sauf si vous recourir à l'abomination qui est un singleton) que vous allez courir dans de multiples erreurs de définition.

Comme un point final, lors de l'utilisation de boost comme un exemple d'en-tête uniquement code, un énorme détail a souvent manqué.

Boost est de bibliothèque, pas de niveau de l'utilisateur code. donc, il ne change pas souvent. Le code de l'utilisateur, si vous mettez tout dans les en-têtes, chaque petit changement va vous amener à avoir à recompiler l'ensemble du projet. C'est une monumentale perte de temps (et n'est pas le cas pour les bibliothèques qui ne changent pas de compiler compiler). Lorsque vous divisez les choses entre en-tête/source et mieux encore, utilisez déclaration à réduire les contient, vous pouvez économiser des heures de recompiler lorsqu'il est ajouté dans une journée.

Answer 2

Le jour des codeurs C++ d’accord sur Le chemin, agneaux va se coucher avec les lions, Palestiniens adopteront israéliens et chats et les chiens seront autorisés à se marier.

La séparation entre les fichiers .h et .cpp est le plus souvent arbitraire à ce point, un vestige des optimisations du compilateur longtemps passé. À mes yeux, déclarations appartiennent dans l’en-tête et définitions appartiennent au fichier d’implémentation. Mais, c’est juste l’habitude, pas de religion.

Answer 3

Code dans les en-têtes est généralement une mauvaise idée car il force la recompilation de tous les fichiers qui inclut l’en-tête lorsque vous modifiez le code réel plutôt que sur les déclarations. Il va également ralentir compilation puisque vous aurez besoin pour analyser le code dans chaque fichier qui inclut l’en-tête.

Une raison d’avoir le code dans les fichiers d’en-tête, c’est qu’il a généralement nécessaires pour le mot clé inline fonctionne correctement et quand utiliser des modèles qui est être instancié dans d’autres fichiers cpp.

Answer 4

Ce qui pourrait être vous informant collègue est une idée que la plupart du code C++ doit être basé sur un modèle permettant de facilité d’utilisation maximale. Et s’il est basé sur un modèle, puis tout devront être dans un fichier d’en-tête, de sorte que le code client peut voir et l’instancier. Si c’est assez bon pour Boost et la STL, c’est assez bon pour nous.

Je ne suis d’accord avec ce point de vue, mais c’est peut-être d'où il vient.

Answer 5

Souvent, je vais mettre les fonctions membres trivial dans le fichier d’en-tête, pour leur permettre d’être Inline. Mais pour y placer l’ensemble du code, juste pour être compatible avec les modèles ? C’est la noix ordinaire.

N’oubliez pas : une consistance stupide est le Super-Bouffon des petits esprits.