Variables globales

Hello,
ca fai plusieurs fois qu'on me di que les déclarations suivantes:

Code:

---

1 2 3 4

extern float var1 extern const float var2

---

sont a éviter dans un programme C. J'aimerai en connaitre la raison si il y en a une? De plus si ces déclarations sont à éviter, comment modéliser une variable/constante globale, commune à tous les fichiers sources du programme?

Une variable hors de toute fonction et non déclarée comme static dans un module C, est globale et est accessible dans tous les modules constituant l'executable.
Pour que cette variable globale soit accessible dans les autres modules, il faut que ces modules la declarent comme extern.
Un bon moyen pour faire cela automatiquement est de mettre la declaration de cette variable "extern" dans le .h du module où se trouve la vraie variable.

Bon c'est pas du tout clair ce que je viens d'ecrire, mais tant pis

mon_module.h

Code:

---

1 2 3 4

/*... */ extern int the_variable; /*...*/

---

mon_module.c

Code:

---

1 2 3 4 5 6

/*...*/ #include "mon_module.h" /*... */ int the_variable; /*...*/

---

main.c

Code:

---

1 2 3 4 5 6 7 8 9 10

/*... */ #include "mon_module.h" /*...*/ int main() { /*.. */ if (the_variable == XXX) /* ... */ }

---

meci de vos réponse :)

il faut redéclarer la variable/constante externe dans chaque fichier ou elle est utilisée? Et pour l'initialisation?

De plus, j'en reviens a ma question: pourquoi dit-on que cette manière de faire est a éviter?

Citation:

---

Envoyé par vinzzzz

ca fai plusieurs fois qu'on me di que les déclarations suivantes:

Code:

---

1 2 3

extern float var1 extern const float var2

---

sont a éviter dans un programme C. J'aimerai en connaitre la raison si il y en a une? De plus si ces déclarations sont à éviter, comment modéliser une variable/constante globale, commune à tous les fichiers sources du programme?

---

Tu as mal compris. C'est le principe même des variables globales (moins de problèmes avec les constantes et variables en lecture seule) qui est à éviter. Tu n'en as probablement pas besoin. C'est tout.

Une meilleure organisation des données (structures, contexte) permet d'éviter ça sauf dans des cas bien précis et plutôt rares.

Mais si tu en a vraiment besoin, il faut le faire bien, et ce que tu as montré est correct.

http://emmanuel-delahaye.developpez....s.htm#globales

Citation:

---

Envoyé par vinzzzz

meci de vos réponse :)

il faut redéclarer la variable/constante externe dans chaque fichier où elle est utilisée?

---

pas redéclarer mais déclarer tout court, oui. C'est un des rôles du .h.

Citation:

---

Et pour l'initialisation?

---

Par défaut (c'est à dire avant la lancement de main()),

Code:

---

int g_maglobale;

---

une globale est initialisée à 0. On peut être plus explicite :

Code:

---

int g_maglobale = 0;

---

ou

Code:

---

int g_maglobale = 123;

---

Citation:

---

Tu as mal compris. C'est le principe même des variables globales (moins de problèmes avec les constantes et variables en lecture seule) qui est à éviter. Tu n'en as probablement pas besoin. C'est tout.

---

Je pense en avoir besoin: dans mon programme j'ai certaines fonctions qui effectuent des calculs et qui utilisent des valeurs qui sont communes a un grand nombre de ces fonctions.
Certaines de ces valeurs sont soit constantes (dans ce cas on peu éventuellement remplacer par des macro), soit variables et modifiables par l'utilisateur (la les variables globales me paraissent indispensables).
Et je trouve qu'utiliser les variables globales est, dans mon cas en tout cas, un moyen pratique et plutot clair ...


En tout cas merci de ta réponse.

Sinon, pour se passer de ces variables super globales, on peut utiliser des "accesseurs" comme en programmation orientée objet.

Code:

---

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

static int var_globale_locale_au_module = VALEUR_PAR_DEFAUT;   int get_variable () { return var_globale_locale_au_module; }   void set_variable (const int valeur) { var_globale_locale_au_module = valeur; }

---

Citation:

---

Une meilleure organisation des données (structures, contexte) permet d'éviter ça sauf dans des cas bien précis et plutôt rares.

---

En prog systeme, on a très souvent besoin de ce type de variables.

Est-ce qu'on ne pourrait pas utiliser ce genre de chose, pour une constante de type numérique j'entend:

Code:

---

1 2 3 4 5

double get_maglobale(){ return 3.14 ; }

---

Bein oui, mais si tu fais que retourner une constante, alors mieux vaut definir une constante ou une constante symbolique ^^


mon_module.h

Code:

---

1 2 3 4 5 6 7

/* ... */   #define MA_CONSTANTE 3.14   extern const double ma_constante2 = 3.14;   /*... */

---

mon_module.c

Code:

---

1 2 3 4 5 6 7 8 9

/* ... */   #incldue "mon_module.h"   /* ... */   const double ma_constante2 = 3.14;   /*... */

---

jsui d'accord avec toi mais comme apparament l'usage des varaibles/cste globales est a éviter si possible... ca pourrait être une solution pour les ocnstantes... autant que les macros d'ailleur en fait..

Citation:

---

jsui d'accord avec toi mais comme apparament l'usage des varaibles/cste globales est a éviter si possible...

---

Oui, enfin tout est relatif, si tu as une ou deux variables globales et que tu les contrôle bien, il n'y a pas de soucis, tant que ça ne devient pas :"tout global" il n'y a rien à craindre.

Citation:

---

Envoyé par vinzzzz

Je pense en avoir besoin: dans mon programme j'ai certaines fonctions qui effectuent des calculs et qui utilisent des valeurs qui sont communes a un grand nombre de ces fonctions.
Certaines de ces valeurs sont soit constantes (dans ce cas on peu éventuellement remplacer par des macro), soit variables et modifiables par l'utilisateur (la les variables globales me paraissent indispensables).
Et je trouve qu'utiliser les variables globales est, dans mon cas en tout cas, un moyen pratique et plutot clair ...

---

Bonjour,
Il semblerait, en tous cas pour mon livre de C, qu'il faille éviter:
«*Evitez de déclarer des variables globales dont le contenu est modifié par les fonctions locales.*»

Citation:

---

Envoyé par vinzzzz

Citation:

---

Tu as mal compris. C'est le principe même des variables globales (moins de problèmes avec les constantes et variables en lecture seule) qui est à éviter. Tu n'en as probablement pas besoin. C'est tout.

---

Je pense en avoir besoin: dans mon programme j'ai certaines fonctions qui effectuent des calculs et qui utilisent des valeurs qui sont communes a un grand nombre de ces fonctions.
Certaines de ces valeurs sont soit constantes (dans ce cas on peu éventuellement remplacer par des macro), soit variables et modifiables par l'utilisateur (la les variables globales me paraissent indispensables).
Et je trouve qu'utiliser les variables globales est, dans mon cas en tout cas, un moyen pratique et plutot clair ...


En tout cas merci de ta réponse.

---

Il y a en fait tres peu de cas ou on est reelement oblige d'utiliser des globales.

Elles sont indispensables (je crois) quand on a besoin d'acceder a des donnees a un moment non connu (interruption par signal par exemple).

Dans la majorite des cas, on peut proceder de la maniere suivante:

1_ definir une structure dans un .h qui contient toutes les variables dont tu te sers partout.

2_ instancier cette structure des le debut du programme (ou des que tu commence a en avoir besoin).

3_ passer un pointeur sur cette structure a toutes tes fonctions.

Avantages:

• Le prototypage des fonctions s'en trouve grandement simplifie.
• Passage de parametres tres leger (un pointeur)
• Facilite pour retrouver toutes ces variables (tu gardes une copie de ta structure a portee de main)

Ca ressemble a ca:

le .h:

Code:

---

1 2 3 4 5 6 7 8

typedef struct { int entier1; int entier2; truc *ptr_sur_un_truc_utile; void *etc; } data_t;

---

la fonction ou tu commences a avoir besoin de tes globales :

Code:

---

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

#include <stdlib.h> #include "mon_header.h"   void my_serious_function(void) { data_t *data;   data = my_malloc(sizeof(*data)); /* my_malloc() verifie la valeur de retour de malloc et exit() si ca se passe mal ;) */ init_data(data); do_the_best(data); do_something_serious(data); do_the_rest(data); return ; }

---

etc...

Tu passes data a toutes tes fonctions et ainsi tu peux acceder a tout ce que tu veux.

Je ne garanti pas que ce soit la meilleure methode, mais je trouve que c'est efficace pour la plupart des cas ou on a besoin d'acceder a des donnes dans un grand nombre de fonctions.

Je trouve cette idée trés bonne, mais par contre l'idée de passer la structure en paramètre dans chaque fonction me dérange un peu. Je trouve ca un peu lourd de faire passer le pointeur a travers tout l'enchainement de fonction. Mais ce n'est qu'une question de gout :).
Finalement j'opterai plutôt pour une structure globale qui contiendrai toutes mes variables globales. Ca ne fait qu'un ou deux pointeurs à gérer je pense que c'est faisable tout en restant clair... ;)

En faisant un petit parallèle avec JAVA (ou même C++ je suppose), les variables statiques, que l'on pourrait (dans une certaine mesure vu que JAVA/C++ sont orienté objet...) comparer avec les globales du C, n'ont jamais posé de problème (dans le sens ou on ne m'a jamais déconseillé de les utiliser) a ma connaissance e tsont bien indispensables dans de nombreux cas... C'est de plus une notion assez intuitive et claire selon moi. C'est pourquoi je ne comprend pas bien pourquoi les variables globales sont a éviter.

Je pense que le principal problème de variables globales (et on parle bien de variables, pas de constante), est tout simplement due à sa portée, et donc à sa durée de vie, et par association à l'utilisation mémoire que cela engendre.

de plus une variable globale est susceptible d'être modifiée par mégarde par les utilisateurs, il faut donc y faire attention.

En revanche, j'ai entendu dire que les variables globales étaient plus interressantes en terme de performance. N'ayant aucune information supplémentaire et preuves à l'appui, je ne peux pas confirmer ou infirmer ceci.

Citation:

---

Envoyé par PRomu@ld

En revanche, j'ai entendu dire que les variables globales étaient plus interressantes en terme de performance. N'ayant aucune information supplémentaire et preuves à l'appui, je ne peux pas confirmer ou infirmer ceci.

---

Cela dépend de l'impléménetation et de la génération du code assembleur. Généralement, si on compile en -O2 ou -O3, l'utilisation d'un pointeur sera plus bénéfique car il faut juste passer le pointeur en argument à chaque appel de fonction.

Lorsqu'on passe par une variable globale, le compilateur va devoir récupérer l'adresse de cette variable, ce qui peut être plus long...

Jc

Citation:

---

Envoyé par Jack_serious

Tu passes data a toutes tes fonctions et ainsi tu peux acceder a tout ce que tu veux.

Je ne garanti pas que ce soit la meilleure methode, mais je trouve que c'est efficace pour la plupart des cas ou on a besoin d'acceder a des donnes dans un grand nombre de fonctions.

---

L'expérience et le bon sens prouvent que c'est la bonne méthode...

Citation:

---

Envoyé par vinzzzz

Je trouve cette idée trés bonne, mais par contre l'idée de passer la structure en paramètre dans chaque fonction me dérange un peu. Je trouve ca un peu lourd de faire passer le pointeur a travers tout l'enchainement de fonction. Mais ce n'est qu'une question de gout :).

---

Il va falloir dépasser ça, parce que c'est la seule façon sérieuse de programmer en C. En C++ ou en Java, ce pointeur est devenu 'invisible' (this).

Citation:

---

Finalement j'opterai plutôt pour une structure globale qui contiendrai toutes mes variables globales.

---

Ouiiiin! Il n'a rien compris... Tu n'as donc pas envie de programmer comme les grands ? Regarde GTK+, c'est un modèle du genre. Sans aller si loin, l'objet FILE du C standard est aussi un bon exemple.

Citation:

---

C'est pourquoi je ne comprend pas bien pourquoi les variables globales sont a éviter.

---

Tu n'as donc pas lu le lien que je t'ai passé au debut ?

• variables exposées à tous les vents
• pas de contrôle d'accès (imagine une base de données...)
• dépendances rendant le code non réutilisable
• code rendu non réentrant (pas d'appels imbriqués, ni récursif, ni concurrentiels).
• code non instanciable...
• pas d'organisation autour des objets