#ifndef
Résolu/Fermé
Caliphe
Messages postés
31
Date d'inscription
dimanche 3 mai 2015
Statut
Membre
Dernière intervention
24 février 2016
-
2 déc. 2015 à 23:05
Caliphe Messages postés 31 Date d'inscription dimanche 3 mai 2015 Statut Membre Dernière intervention 24 février 2016 - 3 déc. 2015 à 18:08
Caliphe Messages postés 31 Date d'inscription dimanche 3 mai 2015 Statut Membre Dernière intervention 24 février 2016 - 3 déc. 2015 à 18:08
1 réponse
[Dal]
Messages postés
6198
Date d'inscription
mercredi 15 septembre 2004
Statut
Contributeur
Dernière intervention
13 décembre 2024
1 096
Modifié par [Dal] le 3/12/2015 à 10:53
Modifié par [Dal] le 3/12/2015 à 10:53
Salut Caliphe;
Dans cette situation tu pourrais faire une "forward declaration", c'est à dire utiliser un type incomplet de struct dans l'include avant le premier usage de la structure non déclarée, ce qui est possible dans ton cas vu que tu n'utilises la
Comme cela (cf. ligne 10 et ligne 12) :
Vois ce document http://www.umich.edu/~eecs381/handouts/CHeaderFileGuidelines.pdf d'un professeur de l'Université du Michigan que je trouve très clair exposant des règles communément admises de bonne gestion du contenu des fichiers .h et notamment le point 8.
Cela dit, si fonctionnellement il n'y a pas de raison de séparer ton code en deux fichiers .h, tu devrais peut-être réfléchir à regrouper les déclarations qui sont toujours utilisées ensemble dans un même .h avec un unique fichier .c correspondant, pour faire un seul module (cf. point 1).
Dal
Dans cette situation tu pourrais faire une "forward declaration", c'est à dire utiliser un type incomplet de struct dans l'include avant le premier usage de la structure non déclarée, ce qui est possible dans ton cas vu que tu n'utilises la
struct Jeuque sous la forme d'un pointeur.
Comme cela (cf. ligne 10 et ligne 12) :
#ifndef INCLUDE_LISTE
#define INCLUDE_LISTE
#include "Jeu.h"
typedef struct Coup{
int a;
int b;
}Coup;
struct Jeu;
Coup* choixCoup(struct Jeu *j);
#endif
Vois ce document http://www.umich.edu/~eecs381/handouts/CHeaderFileGuidelines.pdf d'un professeur de l'Université du Michigan que je trouve très clair exposant des règles communément admises de bonne gestion du contenu des fichiers .h et notamment le point 8.
Cela dit, si fonctionnellement il n'y a pas de raison de séparer ton code en deux fichiers .h, tu devrais peut-être réfléchir à regrouper les déclarations qui sont toujours utilisées ensemble dans un même .h avec un unique fichier .c correspondant, pour faire un seul module (cf. point 1).
Dal
3 déc. 2015 à 18:08
merci beaucoup d'avoir pris le temps de répondre, je ne sais pas pourquoi je n'y avais pas pensé avant, je vais prendre le temps d'étudier le lien que tu m'as proposé.
Pour ce qui est du regroupement dans un même fichier, il y a plus de fonctions dans chaque fichier, je les ai juste simplifié pour une meilleure lisibilité.
Encore merci ;)