Quelle est la différence entre un fichier .h (en-tête) et un fichier .cpp?

Il y a deux considérations ici. Tout d’abord, les fichiers d’en-tête ne sont pas aussi importants en code managé qu’en C ou C ++ natif. Les compilateurs de code managé lisent les déclarations à partir des métadonnées de l’assembly, vous n’écrivez pas (et ne devez pas écrire) les déclarations de type C ++ / CLI qui doivent être visibles dans les autres modules des fichiers d’en-tête. Les obtenir à partir des métadonnées rend vos types disponibles dans n’importe quel langage .NET.

Mais la vraie raison est due au fonctionnement du concepteur de formulaires dans l’EDI C ++. C’est un générateur de code, piloté par les contrôles que vous déposez sur un formulaire ou un contrôle utilisateur et les propriétés que vous définissez dans la fenêtre Propriétés. Il y a un problème très gênant si ce générateur de code doit générer du code dans deux fichiers distincts. Pas tellement le bit de génération, mais la suppression du code lorsque vous modifiez le design du formulaire. La désynchronisation des fichiers rend difficile le diagnostic des erreurs de compilation à partir du code généré automatiquement. Il est plus probable que cela se produise que vous ne le pensez, le générateur de code doit fonctionner avec des fichiers de code source en cours de modification. Très difficile, le code peut ne pas parsingr du tout.

L’IDE C ++ utilise l’approche originale adoptée par les concepteurs C # et VB.NET version 1.1, tout se passe dans un seul fichier. Ce qui est désagréable bien sûr, les déclarations et le code ne doivent pas être mélangés. Cela a été résolu dans ces concepteurs pour la version 2.0 en ajoutant la prise en charge des langages C # et VB.NET pour les classes partielles. Cela ne s’est toutefois pas produit pour C ++ / CLI. On ne sait pas trop pourquoi, l’équipe C ++ / CLI a toujours regardé les ressources limitées par rapport à ces autres équipes. Il n’a pas non plus de support de refactoring, ce qui est très important pour renommer les méthodes lorsque le nom de la classe change. Garder les méthodes en ligne évite le problème.

Anyhoo, vous pouvez obtenir votre code dans le fichier .cpp mais vous devez le faire vous-même. Couper + coller le fait, mais vous devrez également éditer le nom de la classe dans les déclarations de méthode. Il s’agit d’un entretien élevé, demandez-vous si cela en vaut la peine. Pensez également à savoir si vous voulez vraiment utiliser C ++ / CLI pour l’interface utilisateur, c’est un choix peu commun.

Comme d’autres l’ont déclaré, le fichier d’en-tête est destiné aux déclarations de classe, de fonction, de type, etc., tandis que le fichier .cpp doit contenir les implémentations des fonctions. Cependant, un compilateur ne se soucie pas de savoir où le code d’implémentation est écrit pour que vous puissiez mettre tout votre code dans l’en-tête lui-même. Mais cela augmentera le temps de compilation car tout ce code sera compilé dans chaque fichier que vous incluez dans ce fichier d’en-tête.

Garder la mise en œuvre séparée est très utile si vous souhaitez dissortingbuer votre code, mais que vous devez garder le code propriétaire caché. Dans ce cas, vous pouvez créer une bibliothèque à partir du code d’implémentation et dissortingbuer l’en-tête avec la bibliothèque.

L’exception à cela est lors de l’écriture du code de modèle; Dans ce cas, l’implémentation doit aller dans l’en-tête car le compilateur doit le “voir” sur le site d’appel.

Les prototypes de fonctions (que vous appelez les définitions de procédures) doivent figurer dans le fichier d’en-tête (avec les macros). Tout code doit aller dans le fichier .cpp.

Si vous êtes sûr que ce que vous pensez déplacer est du code, il devrait être déplacé ici. Cela aiderait à coller du code.

Les fichiers d’en-tête (* .h) sont supposés contenir les définitions de vos classes, méthodes et types, tandis que les fichiers cpp supposent les détails de l’implémentation. Il est courant d’avoir également des méthodes en ligne et des méthodes courtes dans les fichiers d’en-tête.

Cette pratique n’est pas appliquée par le compilateur, vous pouvez donc écrire l’implémentation (c’est-à-dire le code) dans le fichier d’en-tête.

Personnellement, je déplace ce code généré automatiquement dans les fichiers * .cpp. Dans les fichiers * .h, je laisse des fonctions qui ne vont pas être modifiées très souvent. Je le fais pour être sûr que les temps de compilation ne seront pas très importants après chaque changement que j’ai apporté.