Discussion :

[Kaamui]

Bonjour,

Quelqu'un m'a demandé de lui expliquer où doit on mettre les inclusions et pourquoi cette solution est la mieux. J'ai répondu instinctivement que le mieux est de tout mettre dans le .c comme ça le préprocesseur recopie tout dans le même fichier et que c'est mieux. mais au moment de lui expliquer pourquoi je me suis mélangé les pinceaux.

Si j'ai les fichiers suivants fic1.c, fic1.h, fic2.c, fic2.h, est-il mieux d'inclure fic2.h dans fic1.h ou de l'inclure dans fic1.c, et si fic1.c, pourquoi c'est mieux ? A priori le préprocesseur finirait quand même par tout mettre dans le fic1.c s'il allait chercher le contenu de fic2.h à travers fic1.h, puisque la directive incluant le fic1.h ramènerait les données au final dans fic1.c non ?


A L'AIIIIDEEE !!

[souviron34]

et tu es "ingénieur études et développement" ???

les *h sont des fichiers qui en général servent à définir les interfaces (API) des fonctions à usage externe du fichier .c correspondant.

Si f2.c à besoin de quelques fonctions de f1.c, la définition de ces fonctions (leur prototype) sera mise dans f1.h, et f2.c incluera f1.h, et ainsi de suite.. (par exemple strings.h ou sdtlib.h pour la biblothèque standard)

Sinon, les .h peuvent aussi être utilisés pour définir des types ou valeurs dont l'usage est réparti dans plusieurs fichiers .c (par exemple limits.h pour la biblothèque standard)

[Kaamui]

et tu es "ingénieur études et développement" ???

et je ne sais pas tout, et il m'arrive même très souvent de douter de ce que je sais .... étonnant ? si vous savez tout sur tout et que vous ne remettez jamais en cause vos connaissances les plus basiques, tant mieux pour vous.

les *h sont des fichiers qui en général servent à définir les interfaces (API) des fonctions à usage externe du fichier .c correspondant.

Ok, mais ça répond pas à ma question

Si f2.c à besoin de quelques fonctions de f1.c, la définition de ces fonctions (leur prototype) sera mise dans f1.h, et f2.c inclura f1.h, et ainsi de suite.. (par exemple strings.h ou sdtlib.h pour la biblothèque standard)

Ok, mais ça répond pas à ma question, et c'est ce que j'ai répondu à la personne qui m'a questionné, mais POURQUOI est-ce mieux que f2.c inclut f1.h, alors que : f2.c inclut f1.h qui inclut f2.h fonctionne aussi apparemment ?

Sinon, les .h peuvent aussi être utilisés pour définir des types ou valeurs dont l'usage est réparti dans plusieurs fichiers .c (par exemple limits.h pour la biblothèque standard)

Génial, mais ça répond pas à ma question...

[souviron34]

Ok, mais ça répond pas à ma question, et c'est ce que j'ai répondu à la personne qui m'a questionné, mais POURQUOI est-ce mieux que f2.c inclut f1.h, alors que : f2.c inclut f1.h qui inclut f2.h fonctionne aussi apparemment ?


Génial, mais ça répond pas à ma question...

Sauf qu'on ne sait pas quelle est ta question

Tu ne nous donnes pas les caractéristiques des fichiers concernés...


Dans l'absolu, ce que j'ai dit répond à ta question :

un .h inclue les prototypes des fonctions dont on a besoin à l'extérieur..

POINT FINAL


Si un fichier f1.h inclut f2.h, c'est que f1.c devrait avoir besoin de certaines fonctions de f2.c.

Mais si f2.c inclut f1.h qui inclut f2.h, c'est une erreur de conception....

[Thierry Chappuis]

Si, dans un fichier d'entête, tu déclares une fonction qui utilise dans sont interface un type de donnée comme par exemple size_t (mais c'est valable pour n'importe quel type de donnée), tu inclus le fichier d'entête qui convient directement dans ton propre fichier .h. Ici, par exemple, tu inclus stddef.h directement dans ton fichier .h. Ce ne sera pas au code client de le faire.

Si, dans un fichier d'implantation, tu utilises une structure de donnée, macro ou fonction définie dans une autre unité de compilation, tu inclus le fichier d'entête qu'il faut dans ton fichier d'implantation .c.

La règle de base est relativement simple: il faut inclure le fichier d'entête qui convient à l'endroit où les déclarations qu'il contient sont utilisées.

Avec mes meilleures salutations

Thierry

[souviron34]

Pour précsier encore plus, le principe de fond est le plus petit dénominateur commun :

1. soit un fichier f1.c contenant les fonctions A, B, et C.
   
   
2. soit un fichier f2.c contenant les fonctions D et E
   
   
3. D se sert de A, E se sert de B. C est d'usage interne à f1.c (utilisée par A ou B)
   
   
4. f1.c ET f2.c ont besoin de la définition d'une structure s, et d'une valeur commune LIM

• Pour satisfaire le point 3, il faut avoir un fichier f1.h contenant A et B seulement, qui doit être inclus dans f2.c
  
  
• Pour satisfaire le point 4, il faut avoir un autre fichier .h (par exemple "common.h" ou "structs.h") contenant la définition de s et de LIM seulement, qui doit être inclus dans f1.c ET dans f2.c

Si malgré tout il existe dans f2 des fonctions qui sont nécessaires à f1, c'est que la conception est mal faite, et qu'il fallait faire (éventuellement) un troisième fichier f3, ou regrouper les fonctions au sein du même fichier.