Pourquoi devons-nous écrire un fichier d'en-tête?

Avant de sortir vos commentaires sarcastiques, je sais - c'est une question de nooby. C'est la première fois que j'utilise un langage basé sur C.

Je suis un étudiant de premier cycle qui apprend l'objectif C pour un cours d'informatique sur le développement mobile. Je sais que, dans un milieu universitaire, beaucoup de considérations réelles ne sont pas nécessaires car vous construisez des projets plus petits, travaillez dans des équipes plus petites, etc.

Mais notre professeur exige - et XCode prend en charge - des fichiers d'en-tête .h pour chaque fichier d'implémentation .m. Pour moi, cela semble être un travail très chargé. Je dois m'assurer de copier chaque signature de méthode et variable d'instance dans l'autre fichier. Si je change un fichier, je dois m'assurer qu'il est cohérent avec l'autre fichier. Cela ressemble à un tas de petits ennuis comme ça.

Mais je sais qu'il doit y avoir une utilisation réelle dans les fichiers d'en-tête. Une excellente réponse répondrait à la fois:

1. À quoi sert un fichier d'en-tête pour lequel un fichier d'implémentation n'est pas adapté? Quel est son but?
2. Pourquoi, en tant que programmeurs, devons-nous écrire manuellement nos fichiers d'en-tête? Il semble qu'ils pourraient facilement être générés automatiquement.

Merci d'avance!

1. En bref;

   • Le fichier d'en-tête définit l'API d'un module. Il s'agit d'une liste de contrats qui permet à un tiers d'appeler. Le module peut être considéré comme une boîte noire pour des tiers.

   • L'implémentation implémente le module. C'est l'intérieur de la boîte noire. En tant que développeur d'un module, vous devez écrire ceci, mais en tant qu'utilisateur d'un module tiers, vous ne devriez pas avoir besoin de savoir quoi que ce soit sur la mise en œuvre. L'en-tête doit contenir toutes les informations dont vous avez besoin.

2. Certaines parties d'un fichier d'en-tête peuvent être générées automatiquement - les déclarations de méthode. Cela vous obligerait à annoter l'implémentation car il y a probablement des méthodes privées dans l'implémentation qui ne font pas partie de l'API et n'appartiennent pas à l'en-tête.

Les fichiers d'en-tête contiennent parfois d'autres informations; définitions de type, définitions de constantes, etc. Elles appartiennent au fichier d'en-tête et non à l'implémentation.

La raison principale d'un en-tête est de pouvoir le faire #includedans un autre fichier, vous pouvez donc utiliser les fonctions dans un fichier de cet autre fichier. L'en-tête en contient (seulement) assez pour pouvoir utiliser les fonctions, pas les fonctions elles-mêmes, donc (nous l'espérons) sa compilation est considérablement plus rapide.

Le fait de conserver les deux séparément fait en sorte que personne n'a jamais écrit un éditeur qui automatise très bien le processus. Il n'y a pas vraiment beaucoup de raisons pour lesquelles ils n'ont pas pu le faire, et quelques-uns ont même essayé de le faire - mais les éditeurs qui l'ont fait ne se sont jamais très bien comportés sur le marché, et les éditeurs les plus traditionnels ne l'ont pas adopté.

L'inclusion d'un en-tête permet à votre code d'appeler des fonctions ou des méthodes qui sont écrites ailleurs et qui peuvent ou non faire partie de votre projet / build logiciel, mais qui peuvent être trouvées par l'éditeur de liens lorsque vous construisez le logiciel.

Par exemple, lorsque vous appelez une fonction dans la bibliothèque C standard, vous ne voulez pas avoir à mettre tous les entrailles de cette fonction dans votre projet - vous vous attendez simplement à ce que votre programme puisse l'appeler.

Mais votre compilateur doit être informé que la fonction existe quelque part même si elle ne peut pas voir le code et que l'en-tête le fait. Lorsque le compilateur est terminé, l'éditeur de liens est appelé et il cherche à «lier» les bits de votre code qui restent suspendus, tels que les appels de bibliothèque.

Les fichiers d'en-tête sont principalement utilisés pour déclarer et inclure les signatures (c'est-à-dire le nom de la fonction, la valeur de retour et les arguments) de vos fonctions dans d'autres fichiers. Le compilateur doit connaître ces signatures lors de la compilation et de la liaison de vos fichiers.

Lisez cet article pour plus d'informations.