Pourquoi : 'Global' et 'Static'?

Bonjour à tous et à toutes,

J'apprécie de developper en C, et essaye toujours de réduire au maximum la portée des fonctions et/ou des varibales (variable non-globale et fonction statique) car (selon moi):
-C'était plus logique-cohérent
-C'était plus sécurisé (bien que je n'ai pas l'impression qu'on en parle beaucoup)

Pour la cohérence je reste toujours d'accord.
Mais une question m'est restée, pourquoi est-ce que cela est plus sécurisé?
Est-ce bien vrai?

Y a t-il une différence entre l'espace mémoire d'une variable globale et non-globale (ou de fonction static et non-static)?
Pourriez-vous me donner des exemples concrets?

Merci :D

Bonne journée!

Bonjour,

En ce qui concerne les variables globales, c'est toujours une bonne idée de les éviter. La liste exhaustive des raisons n'est pas toujours facile à établir mais on peut au moins retenir celles-ci :

• Contrairement à celui des variables locales, l'espace des variables globales n'est jamais libéré au cours de l'exécution d'un processus. Ce seul point est déjà, en soi, une raison suffisante pour éviter d'y recourir. :-)
• Les globales ne sont pas établies au même endroit que les locales (qui vont dans la pile) ;
• Les variables globales sont délicates à utiliser avec les threads (et le problème se pose aussi avec les variables statiques). En particulier, les globales sont visibles d'un thread à l'autre (voir Thread Local Storage). Ça peut être un bien comme un mal ;
• L'usage de variables locales permet d'utiliser le même nom de variable là où cela se justifie. Sans notion de portée, on arriverait vite à court de noms valables, ce qui serait très pénible dans le cas de boucles imbriquées, spécialement d'une fonction à l'autre. Imagine un peu que tu ne puisses pas utiliser la variable « x », par exemple, parce l'auteur d'une des nombreuses bibliothèques que tu utilises l'a déjà déclarée en globale pour son propre compte… Ce point-ci est particulièrement important lorsque l'on développe en équipe ;
• Une fonction à variable globale n'est pas ré-entrante : personne ne peut appeler la fonction tant que le premier appelant n'est pas ressorti ;
• Par extension : une fonction à variable globale ne peut pas être récursive (sauf si la variable globale en question est un accumulateur). C'est génant ;
• Enfin, l'utilisation de locales strictement limitées au périmètre qui est censé être le leur permet d'éviter les homonymies : une variable locale invoquée hors de son bloc se traduira par un message « variable indéfinie » à la compilation. S'il reste une globale qui porte le même nom, le code compilera sans erreur et y fera référence plutôt qu'à la locale, à l'insu du programmeur.

Pour les fonctions static, c'est déjà moins grave et moins vérifié par conséquent mais le principe reste le même : éviter de polluer le namespace en mélangeant les appels légitimes et les fonctions à usage interne uniquement, qui ne devraient être appelées que par le programme et pas par l'utilisateur. Cela permet également, en cas de programmation en équipe, de donner la possibilité à deux programmeurs distincts d'utiliser les mêmes noms de fonctions internes sans risquer de se marcher sur les pieds

Concernant ce dernier point, ce n'est pas que du confort : il peut être intéressant d'avoir une fonction par module portant toujours le même nom partout dans un projet, par exemple cleanup().

Si tu es sous unix/linux, tu peux aussi voir que les variables globales et/ou statiques sont accessible/visible depuis l'extérieur de ton exe/lib car elles apparaissent dans sa table des symboles.

Exemple

Code:

---

1 2 3 4 5 6 7 8 9 10

... int VISIBLEGLOB = 0 .. int maFonction { static int VISIBLE = 0; int PASVISIBLE = 0;   return 0; }

---

Code:

---

1 2 3 4 5 6

$nm monProg ... 0000000000600b2c b VISIBLE.2650 0000000000600b28 B VISIBLEGLOB ...

---

Citation:

---

Les globales ne sont pas établies au même endroit que les locales (qui vont dans la pile)

---

Elles sont donc stockées dans le tas? Ou est-ce une autre zone que je ne connais pas?

Je me demandais également, est-ce normal qu'une fonction static apparaissent dans la table des symboles?

En tout cas merci de vos réponses complètes, ca fait plaisir à lire!

Bonne soirée,

Citation:

---

Envoyé par ugo188

Elles sont donc stockées dans le tas? Ou est-ce une autre zone que je ne connais pas?

Je me demandais également, est-ce normal qu'une fonction static apparaissent dans la table des symboles?

En tout cas merci de vos réponses complètes, ca fait plaisir à lire!

Bonne soirée,

---

Visible oui ... mais je ne pense pas qu'elle soit accessible pour autant. Je veux dire par là, que sous linux avec nm, on verra bien le nom de la variable ... mais on ne pourra pas y acceder depuis l'exterier ( juste dans l'unité de compilation, ce qui est normal ).

Citation:

---

Visible oui ... mais je ne pense pas qu'elle soit accessible pour autant.

---

Ah bah je pensais...
Faudrait faire des tests :)

stack overflow?
http://nicolasj.developpez.com/articles/pieges/

Bah si on parle de globale se serait plutôt 'heap overflow',
puisqu'elles ne semblent pas être stockée sur la pile. :P

Non, les variables statiques ne sont pas stockées dans le tas, mais dans une autre zone:

http://de-lafond.com/La%20doc/Les%20...1/memoire.html

Citation:

---

Envoyé par haraelendil

Non, les variables statiques ne sont pas stockées dans le tas, mais dans une autre zone:

http://de-lafond.com/La%20doc/Les%20...1/memoire.html

---

si j'en crois nm concernant les static

Citation:

---

0000000000600b2c b VISIBLE.2650
0000000000600b28 B VISIBLEGLOB

"B" The symbol is in the uninitialized data section (known as BSS).

---

Euh....Je lis ce sujet et je pose une question bête : c'est quoi le tas ? :oops:

Citation:

---

Envoyé par Bktero

Euh....Je lis ce sujet et je pose une question bête : c'est quoi le tas ? :oops:

---

http://fr.wikipedia.org/wiki/Allocation_de_m%C3%A9moire

Merci bien ! ;)