portée d'un #define

Bonjour à tous,

Voici mon problème,
J'ai un projet avec de nombreux fichiers .c et .h
pour faciliter la visibilité je définis toutes toutes mes constantes précompilo dans un seul fichier .h
Celles-ci sont ensuite réutilisées dans d'autres fichier .h

exemple dans mon fichier definitions.h
je défini:

Code:

---

1 2 3 4 5 6 7

#ifndef DEFINITIONS_H_ #define DEFINITIONS_H_   #define TAILLE_MAX 1000   #endif

---

ensutie dans mon fichier toto.h

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

#ifndef TOTO_H_ #define TOTO_H_   typedef struct { int numero; double flotant; char nom_du_truc[TAILLE_MAX]; } PROPERTY_DEF;   #endif

---

sous VS 2008, pas de porbs, ça passe.

Par contre avec gcc, j'obtiens l'erreur:

Code:

---

1 2	toto.h|8|error: `TAILLE_MAX' undeclared here (not in a function)

---

je précise que definitions.h n'est inclu que dans main.h lui même inclu dans main.c
qu'il n'y a jamais de #UNDEF TAILLE_MAX dans mon code

d'après mes maigres connaissances, à partir du moment ou un #define est défini une fois, il a une portée sur tout le code.

J'ai tenté de mettre une priorité de compil pour compiler le main.c en premier (afin d'être sûr que TAILLE_MAX soit défini avant d'être utilisé par le préprocesseur), mais rien n'y fait.

J'ai loupé quelque chose? je dois spécifier un argument spécial à GCC?

Vous n'avez pas inclut votre fichier de define avant l'utilisation de la constante ( avant la struture ). ( Votre fichier "definitions.h" )
Ainsi donc, le compilateur ne sait pas encore ce qu'est le TAILLE_MAX

Je m'en dotais un peu.

Je précise donc ma question.
le fichier definitions.h est inclu dans main.h. mais pas dans toto.h.
je demande a compilo de compiler main.c qui inclu main.h qui inclu definitions.h.
en priorité (dans C::B propriétés de main.c/build/priorityweight =0)
Le précompilateur doit donc d'après moi d'abord parser definitions.h avant toto.h.
Donc qd il rentre dans toto.h TAILLE_MAX doit déjà être défini.

Je le répète, ceci fonctionne parfaitement sous VS2008, pourquoi pas avec C::B?

Comment faire e sorte d'être sûr qu'un header soit lu en premier par le précompilo?:calim2:

Pourquoi n'est-t-il pas inclus dans toto.h ?
Un fichier d'en-tête doit se suffire à lui-même. La seule exception que je m'autorise est <windows.h> quand je compile sous Win32, car il est un peu particulier.

Citation:

---

Pourquoi n'est-t-il pas inclus dans toto.h ?

---

Pour une question de lisibilité, j'ai plus de 50 fichiers .h dans ce projet.
le fichier defintions.h est utilisé dans une bonne partie de ceux-ci.
Ceux-ci comportent déjà pas mal d'#include et je ne veux pas en rajouter. (c'est un léger comme argument?)

Ce que je ne comprends pas, c'est que dans les logs du compilo, je vois que definitions.h est traité avant toto.h donc d'après moi, TAILLE_MAX devrait déjà être défini.

Qu'est ce qui peut faire qu'il n'est plus défini?


NB: effectivement, si j'ajoute #include definitions.h dans toto.h, je n'ai plus de problèmes...

Bonjour,
je n'arrive pas bien à suivre tes descriptions et à comprendre qui inclut qui.

Essaye de trouver un code minimum qui reproduise le problème et poste-le dans son intégralité.

Mais d'une manière générale, l'ordre d'inclusion des headers est complètement déterminé par les #include.
Aucun compilateur ne s'amuse à choisir dans quel ordre il les inclut.
Je ne vois pas comment ça peut fonctionner avec un compilateur et pas avec un autre.
A moins bien sûr, d'utiliser des defines prédéfinis par le compilateur lui-même (genre DEBUG ou WIN32). Mais ça n'a pas l'air d'être le cas.

Il faut imaginer que le préprocesseur remplace chaque ligne #include par le contenu du fichier inclus.
Il y a des options du compilateur qui permettent de récupérer le fichier "préprocessé", comme ça tu verras s'il y a un problème d'ordre d'inclusion.

Une bonne règle à suivre est d'avoir toujours des headers autonomes. C-à-d qui ne dépendent pas d'autres headers devant être inclus avant lui.
---
Oops ! le temps que je compose mon message, d'autres réponses sont arrivées...

Merci infiniment sopsag.

Tes explication:

Citation:

---

Il faut imaginer que le préprocesseur remplace chaque ligne #include par le contenu du fichier inclus.

---

clarifient tout pour moi.

J'ai tenté de reproduire le problème sans y parvenir.

en utilisant l'option -E de GCC pour obteir un fichier préprocessé, je me suis rendu compte qu'un vieux header trainait dans mes sources. celui-ci faisait appel à un autre header qui n'existe plus.

Je l'ai viré et tout fonctionne maintenant...:mouarf:

Désolé de vous avoir fait predre votre temps, cependant merci d'avoir tout clarifié.

bonne journée.