inclusion dans le .h ou le .c

Version imprimable

10/01/2012, 10h15
Kaamui

inclusion dans le .h ou le .c

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 ?:aie:

A L'AIIIIDEEE !! :lol:
10/01/2012, 11h27
souviron34

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

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)
10/01/2012, 11h44
Kaamui

Citation:

Envoyé par souviron34

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

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.

Citation:

Envoyé par souviron34

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

Citation:

Envoyé par souviron34

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 ?

Citation:

Envoyé par souviron34

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...
10/01/2012, 12h09
souviron34

Citation:

Envoyé par Kaamui

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 :mouarf:

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....
10/01/2012, 12h30
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
10/01/2012, 13h09
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.
10/01/2012, 13h43
diogene
C'est une question de logique dans l'organisation du programme.

Considérons une unité de compilation unit1 constituée d'un unit1.c et du unit1.h associé

1- unit1.h contient les définitions de types, les prototypes,... qui peuvent être utilisés dans une autre unité de compilation unit2. Les définitions non utilisées ailleurs restent dans unit1.c. unit1.h ne doit pas comporter de définitions de variables ni du code exécutable.

2- unit1.h fait des #include pour les définitions extérieures qui figurent dans unit1.h

3- unit1.h en général comporte des protections contre les inclusions multiples

4- unit1.c fait un #include de unit1.h pour assurer la cohérence de unit1 en permettant de n'avoir qu'un endroit pour ces définitions

5- unit1.c fait des #include pour les définitions extérieures qui figurent dans unit1.c (on peut se limiter à celles non utilisées par unit1.h). C'est préférable de ne pas mettre ces include dans unit1.h parce ce dernier a vocation à être inclus dans d'autres unités de compilation où elles n'ont rien à faire ou pourraient même entrer en conflit avec d'autres définitions.

Un exemple
```
unit1.h                                      unit1.c

#ifndef unit1H  // cf(3)                     #include <stdio.h> // pour le FILE cf(5)
#define unit1H  // cf(3)                     #include "unit1.h"  // cf(4)
#include <stdlib.h> //pour le size_t cf(2)   typedef enum {A,B,C} Enum;   //cf(1)
/*--------------*/                           void fonc2(FILE* f, Enum e, Struct * s); //cf(1)
typedef struct                               /*-----------------------------*/
{                                            int var;
   size_t a;                                 void fonc1(Struct * s){....}
}Struct;                //cf(1)              static void fonc2(FILE* f, Enum e, Struct * s){....}                         
void fonc1(Struct * s); //cf(1) 
extern int var;         //cf(1)
#endif       //cf(3)
```
10/01/2012, 14h25
Bousk

A mon ancien poste on favorisait les forward declaration pour limiter les inclusions dans les .h, pour que la compilation soit plus rapide.

Sinon, ton inclusion tu peux la mettre où tu veux dans l'absolu. Il faut juste que toutes les données utilisées soit déclarées (inclusion ou forward declaration).
10/01/2012, 15h07
Kaamui

@souviron34 : Désolé je me suis trompé dans ma réponse, mais les réponses qui ont suivi la votre répondent parfaitement à ma question, y compris votre deuxième et troisième réponse.

Citation:

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

complètement ! :mouarf: je voulais dire : f2.c inclut f2.h qui inclut f1.h comparé à f2.c inclut f1.h et f2.h

Citation:

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

Merci :), donc cela dépend des caractéristiques des fichiers concernés

@Thierry Chappuis : merci, donc cela dépend du cas de figure.
@diogene : ok, question de logique

ok, donc si j'ai bien retenu la leçon, zero-overhead ? comme je ne fais plus de C depuis un moment, je ne pensais plus à tous ces cas de figure, mais si je comprend bien il s'agit d'inclure les fichiers nécessaires exclusivement là où ils le sont

Merci à tous.

Pour info, je n'ai apprécié votre attaque sur ma légitimité à être à mon poste "d'ingénieur étude et développement" je suis un autodidacte (sans diplôme) à un poste de bac+5 je trouve que je ne m'en sors pas trop mal, même si je peux avoir encore des questions toutes bêtes parfois.
10/01/2012, 16h12
souviron34

Citation:

Envoyé par Kaamui

Pour info, je n'ai apprécié votre attaque sur ma légitimité à être à mon poste "d'ingénieur étude et développement" je suis un autodidacte (sans diplôme) à un poste de bac+5 je trouve que je ne m'en sors pas trop mal, même si je peux avoir encore des questions toutes bêtes parfois.

Désolé, ce n'était pas mon intention, et, ne pouvant connaître votre parcours, vu qu'il n'est pas rare ici d'avoir des jeunes diplômés qui ont la grosse tête, c'est ce que je pensais que vous étiez..

Mais ma remarque était plutôt d'ordre général, ce que vous avez compris avec les derniers posts : c'est une question de logique : circonscrire au plus près la portée..

Toutes mes excuses..

Citation:

Envoyé par Kaamui

Merci :), donc cela dépend des caractéristiques des fichiers concernés

Ben, a priori oui, pusique cela dépend du code qu'il y a dedans ;)

En raisonnant en termes généraux comme dans votre premier post, on ne pouvait rien déduire... (comme la note sur la mauvaise conception le prouvait : on ne savait pas si c'était ce qui était fait, ou autre chose)
10/01/2012, 16h37
Kaamui

Merci,

Le principal est que vous m'avez tous permis d'enrichir mes connaissances (et c'est pas la première fois ;) ) et je vais pouvoir répondre correctement à la personne qui m'a demandé conseil (un lien vers cette page devrait suffir maintenant :) )

Très cordialement,