include et variable globale

Bonjour et bonne annee a tous!
Visiblement en cette nouvelle annee je me rend compte que j'ai un probleme avec les variables a partager a plusieur fichier.
Voici le probleme:
J'ai un projet avec N fichier .c, dans chaque fichier source il y a aumoins une fonction qui accede a une ressource externe (USB, Serveur X...) ce que je veux faire c'est creer 3 variables:RES_INFO RES_ACCESS et RES_ERROR. ces variables sont dans ressource.h (qui n'a pas de ressource.c) et doit etre inclut dans tout les .c. Ces deux variables serve a signaler quelle fonction a accede a quoi et quelle erreur genre
fonction getRadarInfo:

Code:

---

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

struct USBstr *getRadarInfo(struct *usb) { RES_ERROR=NONE; RES_INFO=DEVICE_USB ; RES_ACCESS=0xA1; //code d'identification de la fonction appellante ... ... //fait quelque chose avec l'usb if(usb->result==NULL) { RES_ERROR=ERROR_DEVICE_USB_DATA; ... } ... }

---

le but est de pourvoir lire savoir a tout moment qui est le dernier a avoir vais appelle a un des devices inscrit dans la liste et connaitre la nature de l'erreur.

le probleme c'est que a la compilation on me parle de multiple declaration des 3 variable

Code:

---

1 2 3 4 5 6 7 8

#ifndef __RESSOURCE_H_ #define __RESSOURCE_H_   unsigned int RES_ERROR; unsigned char RES_INFO; //maximum 256 devices unsigned int RES_ACCESS;   #endif

---

donc des que le premier fichier a inclut les autres se pleignent.

Bonjour,

Je dirai : Heureusement que les autres se plaignent! Il faut savoir que gcc est une aide au processus de compilation mais pour comprendre ton problème il faut bien comprendre ce procédé.

Prenons le cas d'un

Code:

---

gcc foo.c bar.c

---

Lorsque tu tapes cette commande, en fait gcc va faire, en gros (j'omet les étapes intermédiaires, préprocessing link etc..) :

Code:

---

cc foo.c

---

puis

Code:

---

cc bar.c

---

Ce qu'il faut retenir c'est qu'on produit là 2 fichiers dits "objets" (les .o) bien distincts. Un fichier objet comporte ce que l'on appelle des symboles qui sont ensuite "utilisés" par le linker. Et ces symbols sont déterminant pour que ton linker sache que telle fonction que tu appelles ou telle ou telle variable que tu utilises dans foo.c est en fait en défini dans bar.c. Pour info, c'est pour cela, par exemple, si tu en as entendu parler, que la convention d'appel des fonctions est très importante. Le nom du symbol exporté varie selon elle (Sous gcc, le défaut est __cdecl, qui précède le nom de ta fonction par un "_" et le fait suivre par un "@" et la somme des tailles en mémoire de tes arguments. C'est à dire qu'une fontion qui prend 2 int sera, sous x86 et pour un int de 4 octets, égale à 8. Donc "int mafonction(int,int);" deviendra donc "_mafonction@8"). C'est pour cela, par exemple, que tu dois par exemple préciser "extern C" dans des fichiers C++ qui a un système de symboles totalement différent du C. Ou encore préciser "__cdecl" selon le compilo (Et parfois même 2 objets C comme foo.c et bar.c compilés avec 2 compilos différents peuvent poser problème, si par exemple les tailles des types de bases ne correspondent pas!).

Donc en gros lorsque tu déclares une variable dans foo.c, tu lui dis de déclarer tel symbol à tel endroits de l'exécutable final (l'endroit est défini par le ld, je te passes les détails). Et lorsque tu utilises les headers, c'est juste pour dire au compilo (et non au linker) : "t'inquiètes pas, tu connais pas cette fonction/variable, mais fais sans, le linker le trouvera dans un autre fichier objet!".

Maintenant en quoi cela t'intéresse? Tout simplement parce que lorsque tu inclus LES DECLARATIONS de variables dans un header inclut dans 2 fichiers "linkés" ensembles, foo.c et bar.c, tu exportes les mêmes symbols dans les deux fichiers objets générés. Donc le linker n'a pas de moyens de savoir auquel des 2 tu fais référence dans tel fichier (renseignes toi aussi sur le mot clé "static").

Donc imagines si le linker ne se plaignait pas, un coup tu rajoutes 1 à RES_ERROR, c'est celui déclaré dans foo.c qui prend. Le coup d'après, tu retire 1 à RES_ERROR, c'est celui de bar.c qui prend.

En résumé, pour résoudre ce problême, tu dois déclarer ces variable dans un des 2 .c et dans l'autre déclarer ces variables précédés de "extern". Qui a la même fonction que lorsque tu places un prototype dans tes headers. Dire au compilo que le linker "trouvera son adresse" dans un autre .o.

Cordialement

Merci pour ta reaction.
et je crois avoir bien compris le probleme seulement pour le contourner du me demande de declarer ma global dans l'un et la redeclarer dans l'autre en rajoutant extern.
donc dans me cas precis je declare dans le .h et je redeclare avec extern dans chaque fichier utilisant les globales?

ps je vois pas pourquoi tu me parle de static qui n'a aucune utilite dans mon probleme.
a la rigeur je peux contourner en faisant un fichier resource.c avec a l'interrieur mes 3 variable declarer en static et dans le ressource.h:

Code:

---

1 2 3 4 5 6 7

#ifndef ... unsigned char getRESinfo(); unsigned int getRESerror(); unsigned int getRESacces(); void setRESinfo(unsigned char code); void setRESerror(int code); void setRESacces(int code);

---

j'y avais pense mais j'ai pas eu envie d'avoir un fichier.c avec juste a l'interriere:

Code:

---

1 2 3 4

#include "include/ressource.h" static unsigned char RES_INFO; static unsigned int RES_ERROR; static unsigned int RES_ACCESS;

---

Citation:

---

Envoyé par lilington

donc dans me cas precis je declare dans le .h et je redeclare avec extern dans chaque fichier utilisant les globales?

---

Presque! Tu déclares le dans un des .c et tu les déclares dans l'autre .c en extern.

Citation:

---

Envoyé par lilington

ps je vois pas pourquoi tu me parle de static qui n'a aucune utilite dans mon probleme.
a la rigeur je peux contourner en faisant un fichier resource.c avec a l'interrieur mes 3 variable declarer en static et dans le ressource.h:

Code:

---

1 2 3 4 5 6 7

#ifndef ... unsigned char getRESinfo(); unsigned int getRESerror(); unsigned int getRESacces(); void setRESinfo(unsigned char code); void setRESerror(int code); void setRESacces(int code);

---

j'y avais pense mais j'ai pas eu envie d'avoir un fichier.c avec juste a l'interriere:

Code:

---

1 2 3 4

#include "include/ressource.h" static unsigned char RES_INFO; static unsigned int RES_ERROR; static unsigned int RES_ACCESS;

---

---

Ahaha Le C++ est encré en toi cher ami :mouarf: Non c'est une possibilité certe mais le static est plutôt là lorsque tu ne veux pas que tes variables soient vues par le linker. Ca sert souvent dans des moyens/gros projets où tu veut être sûr que ta variable globale n'interferera pas avec les variables dans d'autres .c. Tout comme lorsque tu déclares une fonction static

Cordialement.

Citation:

---

Envoyé par baccali

Presque! Tu déclares le dans un des .c et tu les déclares dans l'autre .c en extern.

---

Juste une petite precision, vu cette dernier intervention cite et ta belle explication sur gcc et ld, je n'ai donc plus besoin du .h (sauf peut etre a titre explicatif pour les autres du projet?)

Citation:

---

Envoyé par baccali

Ahaha Le C++ est encré en toi cher ami :mouarf: Non c'est une possibilité certe mais le static est plutôt là lorsque tu ne veux pas que tes variables soient vues par le linker. Ca sert souvent dans des moyens/gros projets où tu veut être sûr que ta variable globale n'interferera pas avec les variables dans d'autres .c. Tout comme lorsque tu déclares une fonction static

Cordialement.

---

le projet est justement genre moyen vers grop. et oui c'est un heritage de C++ language que je deteste cordialement (pas autant que java mais je deteste quand meme). Sinon je suis tente de dire que c'est C++ qui a copier le static du C dans ses classes ( :mouarf: aussi).
bon j'ai pas teste mais je te fais confiance je marque resolut en attendant de pouvoir m'assurer que tout marche.

edit: j'ai fais un petit programme test rapide soit t1.c t2.c main.c i.h
et ca a marche
main:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

#include "in.h" #include <stdio.h>     int main() { extern int RES;   setDVI(); printf("Last device call #%d\n",RES); setVGA(); printf("Last device call #%d\n",RES); setHDD(); printf("Last device call #%d\n",RES); setusb(); printf("Last device call #%d\n",RES); setHDD(); setusb(); printf("Last device call #%d\n",RES); return 0; }

---

t1.c

Code:

---

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

#include "in.h"   extern int RES;   void setusb() { RES=1; }   void setHDD() { RES=4; }

---

t2.c

Code:

---

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

#include "in.h"   extern int RES;   void setDVI() { RES=0; }     void setVGA() { RES=3; } ~

---

et l'include:

Code:

---

1 2 3 4 5 6 7 8

#ifndef __IN_H_ #define __IN_H_ int RES; void setDIV(); void setVGA(); void setusb(); void setHDD(); #endif

---

bon ca marche mais est-ce propre. je rappelle que dans les projets les autres devront appeller ma lib donc ca doit vraiment etre propre Merci.

une autre question en rapport:
en attendant une reponse je suis aller jeter un coup d'oeil dans errno.h etant donne que errno a justement le comporte que je cherche et la je vois

Code:

---

1 2 3

#ifndef errno extern int errno; #endif

---

la question c'est alors ou est declare errno?
je pense tout betement de c'est dans libc.so
edit: en tapant nm -D /lib64/libc.so.6|grep errno j'ai:

Citation:

---

00000030b0821ae0 T __errno_location
00000030b0907600 T __h_errno_location
00000030b091d2e0 T clnt_perrno
00000030b091d270 T clnt_sperrno
0000000000000010 B errno
000000000000005c B h_errno

---

je crois sans me tromper que j'ai repondu a ma question

Citation:

---

Envoyé par lilington

Juste une petite precision, vu cette dernier intervention cite et ta belle explication sur gcc et ld, je n'ai donc plus besoin du .h (sauf peut etre a titre explicatif pour les autres du projet?)

---

Citation:

---

Envoyé par lilington

bon ca marche mais est-ce propre. je rappelle que dans les projets les autres devront appeller ma lib donc ca doit vraiment etre propre Merci.

---

Tout dépend de si c'est utile ou non. Si tu comptes faire un appel de fonction qui se trouve dans un autre module (.c), tu dois prévenir le compilo et l'informer sur la fonction que tu appelles. Après c'est à toi de voir. Tu peux tout aussi bien placer ton header dans ton module directement mais vu que dans notre cas tu codes une librairie que d'autres vont utiliser, le mieux c'est de leur passer ton (.o ou .so) et ton header plutôt que tu ailles voir chacun pour leur donner la liste de tes fonctions et de leurs arguments, les fichiers à inclures etc... tu ne penses pas?

Citation:

---

Envoyé par lilington

je crois sans me tromper que j'ai repondu a ma question

---

nice :ccool:

Bon courage pour votre projet.
++

Citation:

---

Envoyé par baccali

Tout dépend de si c'est utile ou non. Si tu comptes faire un appel de fonction qui se trouve dans un autre module (.c), tu dois prévenir le compilo et l'informer sur la fonction que tu appelles. Après c'est à toi de voir. Tu peux tout aussi bien placer ton header dans ton module directement mais vu que dans notre cas tu codes une librairie que d'autres vont utiliser, le mieux c'est de leur passer ton (.o ou .so) et ton header plutôt que tu ailles voir chacun pour leur donner la liste de tes fonctions et de leurs arguments, les fichiers à inclures etc... tu ne penses pas?
++

---

Oui justement c'est pourca que j'insiste pour le .h plutot que de declarer dans l'un des .c.
sinon merci pour ton aide tres utile et les encouragements

Il me semblait avoir vu une fois quelque chose du genre :

Code:

---

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

#ifndef RESSOURCES_H #define RESSOURCES_H   #ifdef VAR_GLOBALES int VAR_1=1; char VAR_2[]="deux"; #else extern int VAR_1; extern char VAR_2[]; #endif   #endif

---

Il suffisait alors de définir VAR_GLOBALES dans un fichier C, comme baccali propose de déclarer les variables. L'intérêt était qu'on centralisait toujours les déclarations dans le fichier ressources.h.

Mais impossible de retrouver la formulation exacte... :cry:


EDIT : ah j'ai réussi à faire compiler le truc !

Code:

---

1 2 3 4 5 6 7 8 9 10 11

#include "afficherInt.h" #include "afficherString.h" #include <stdio.h>   int main(void) { afficherInt(); afficherString();   return 0; }

---

Code:

---

1 2 3 4 5 6 7 8 9

// La ligne importante est la suivante /!\ #define VAR_GLOBALES #include "ressources.h" #include <stdio.h>   void afficherInt(void) { printf("VAR_1 = %d\n",VAR_1); }

---

Code:

---

1 2 3 4 5 6

#ifndef AFFICHER_INT_H #define AFFICHER_INT_H   void afficherInt(void);   #endif

---

Code:

---

1 2 3 4 5 6 7

#include "ressources.h" #include <stdio.h>   void afficherString(void) { printf("VAR_2 = %s\n",VAR_2); }

---

Code:

---

1 2 3 4 5 6

#ifndef AFFICHER_STRING_H #define AFFICHER_STRING_H   void afficherString(void);   #endif

---

C'est fiable ça ?

Pour cette dernière solution, pourquoi ne pas faire plutôt

Code:

---

1 2 3 4 5 6 7 8

#ifndef VAR_GLOBALES #define VAR_GLOBALES int VAR_1=1; char VAR_2[]="deux"; #else extern int VAR_1; extern char VAR_2[]; #endif

---

cette partie du code est volontairement en dehors du

Code:

---

1 2 3

#ifndef MYFILE #define MYFILE #endif

---

après il suffit de #include "resources.h" où bon nous semble, sans se soucier où est ou n'est pas défini VAR_GLOBALES
?

Ne marche pas.
Les processus de compilation des unités de compilation (.c) d'un ensemble sont indépendants les uns des autres.
VAR_GLOBALES, pour chaque unité de compilation, sera non défini au départ de la compilation de l'unité et l'éditeur de liens va se retrouver ensuite avec des définitions multiples des variables.

@Diogene : C'est la solution de Bousk ou la mienne qui ne marche pas ?

De ce que je comprends, la mienne :aie:

Citation:

---

Envoyé par Bousk

De ce que je comprends, la mienne :aie:

---

Bien compris

C'est ce que je pensais aussi. Je me dit aussi que si Diogene ne m'a pas tapé, c'est que ma méthode doit être valide :aie:

valide, oui, mais peu répandue..

La plus répandue (et c'est logique) est celle mentionnée par baccali (post de 7h)

En effet, la plupart du temps de telles valeurs (bien que en petit nombre) ne sont pas à "publiciser" trop : en général dans 1 ou 2 modules seulement, pas dans l'ensemble de la biblothèque (et en général c'est utilisé par flemme de refaire des setters/getters, ou pour tester un cas de figure).

Merci pour toutes vos interventions, je comprend mieux.
Sinon l'idee de devoir declarer extern dans chaque fichier me plait pas trop je vais donc essayer d'imiter le comportement de errno

Citation:

---

Envoyé par lilington

Sinon l'idee de devoir declarer extern dans chaque fichier me plait pas trop je vais donc essayer d'imiter le comportement de errno

---

8O :cfou:

C'est bien ce qu'on fait avec errno !!!!

Citation:

---

Envoyé par lilington

je suis aller jeter un coup d'oeil dans errno.h etant donne que errno a justement le comporte que je cherche et la je vois

Code:

---

1 2 3

#ifndef errno extern int errno; #endif

---

la question c'est alors ou est declare errno?

---

En plus, tu l'as dit toi-même :)

Je crois que vous n'avez pas bien compris mon message.
je veux eviter de faire des

Code:

---

extern int truc;

---

dans chacun de mes fichier .c
c'est la premiere solution qui m'a ete propose avec une belle explication.

mais c'est pas grave je sais que je m'exprime mal

au risque e me répéter, si tu as à le faire dans beaucoup (mais pas tous) de fichiers, ce n'est pas la bonne solution non plus...

La vraie solution est d'avoir un "getter/setter"..

L'usage d'avoir à déclarer un "extern" (même centralisé dans un seul include) est pour un usage ponctuel (ce qui est le cas de errno.h : il y a très peu de modules où on en a besoin)

Sinon il vaut mieux faire un :

Code:

---

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

static int MyVal ;   void SetValue ( int Value ) { MyVal = Value ; }   int GetValue ( void ) { return MyVal ; }

---

Dans le module "principal", et appeler les fonctions depuis les sources où c'est nécessaire...

Oui justement la methode que tu donnes on en avait parle a la page precedente d'ou la remaque de baccali sur l'influence du C++ que j'aime pas d'ailleur.

Sinon c'est gentil ce genre d'interventions qui clarifient bien mon esprit tordu et sinueux.