Discussion :

[say]

Bonjour,
il m'a semblait lire régulièrement que l'utilisation de variables globales, ce n'était pas très propre comme programmation...alors, je m'interroge...
pourquoi et quelle alternative?

Peros, j'ai des objets que j'ai besoin de pouvoir accèder systèmatique, de manière simple. j'ai donc fait un fichier constants.h qui contient mes variables globales...commence à y en avoir kkues unes. j'ai vu faire ça sur le forum. ça répond bien à mon problème mais j'ai l'impression que ça gêne pas mal de monde.

s'agit-il que de puristes?

merci, tch'o

[jobigoud]

Première idée, quand tu relis ton code, pour une fonction donnée, tu dois pouvoir comprendre ce qu'elle fait juste avec son entrée et sa sortie et son intitulé. Si elle modifie une globale, tu vas devoir le préciser dans un commentaire ou lire tout le code de la fonction pour le savoir. Ca correspond à un effet de bord de ta fonction...

Ensuite n'importe quel partie du programme peut appeler la globale. Si tu en modifie le type ou même le nom, tu va devoir tracer tout le code à la recherche des dépendances.

J'imagine qu'il doit y avoir d'autres raisons, voilà déjà pour l'instant

[slylafone]

Parce qu'il existe le pattern Singleton. Il permet d'accéder à des variables / fonctions globales de manière plus controlée.

[Gilles Louïse]

il m'a semblé lire régulièrement que l'utilisation de variables globales, ce n'était pas très propre comme programmation...alors, je m'interroge...
Pourquoi et quelle alternative?

Ce n'est pas très bon parce que si vous avez plusieurs fichiers, vous allez devoir déclarer des "extern" et un programme devient rapidement illisible, c'était l'ancienne technique de programmation.

Ce qu'on fait en C++, c'est tout simplement de mettre les variables générales dans la classe principale, dans la zone "public". Ainsi la variable n'est plus isolée, elle devient membre de la classe principale.

Même chose pour les fonctions, on évite de les isoler, les sous-programmes généraux deviennent des membres de la classe principale et sont par là même accessibles partout.

C'est la méthode classique en POO.

Si vous avez une variable v ou une fonction f, vous écrirez simplement v ou f tant que vous êtes "chez vous" c'est-à-dire dans la classe principale, Form1 par défaut, encore que vous pouvez écrire Form1->v ou Form1->f même si ce n'est pas nécessaire puisqu'on est par hypothèse dans Form1. Si toutefois, vous voulez accéder à v ou f depuis une autre classe C, il faudra simplement écrire C->v ou C->f pour y accéder.

À bientôt
Gilles

[say]

bien, effectivement il y a des [bonnes] raisons.

ce qui me chagrine, c'est que dans ces solutions, ça suppose qu'un objet est instancié... et que la classe soit incluse dans chaque classe qui en a besoin. en plus, les accès se font par un objet.

bref, j'ai pas de bonnes raisons mais je trouve pas ça pratique.

moi j'ai une unité Constants.h qui contient mes macros et mes définitions de variables globales, mes constantes. je vais même jusqu'à mettre mes include ici, ce qui me permet de n'avoir à inclure que constants.h par la suite..


pourquoi ai-je l'impression que je fais n'importe quoi??

enfin ça marche malgré tout...ce qui est quand même ce qu'on attend de l'appli

A+

[Gilles Louïse]

ce qui me chagrine, c'est que dans ces solutions, ça suppose qu'un objet est instancié

Si vous faites une application standard avec C++ Builder, on a bien une classe instanciée par défaut, la classe principale TForm1.

et que la classe soit incluse dans chaque classe qui en a besoin

Pas du tout. La seule variable globale, c'est le pointeur vers Form1, il est lisible depuis n'importe quel endroit. Il n'est donc pas nécessaire d'inclure la classe principale dans chaque classe.

en plus, les accès se font par un objet.

Si on est "chez nous", on accède directement à la variable sinon oui, il faut préciser l'objet.

Si vous n'avez pas de classe principale, ça change effectivement tout mais c'est très curieux. On se demande bien quelle application n'aurait pas de classe principale.

L'important effectivement est que ça marche, c'est la vraie notation de votre programme. Faites comme vous l'entendez, je vous indiquais simplement la marche à suivre fréquente en POO et pour ma part, ça m'a l'air très pratique.

À bientôt
Gilles

[say]

re,
oui, bien sur j'ai une classe principale...je serais bien embêtée sinon.

En fait, je disais que ça marchait et que c'était le principal pour me dédouaner d'avoir à refaire un peu d'organisation.

mais j'ai bien tout noté, et je me doutais que je n'étais pas forcèment sur la bonne voie.

je vais réfléchir à tout ça.

merci beaucoup en tout cas.

bonne continuation

[diogene]

j'ai l'impression que ça gêne pas mal de monde.
s'agit-il que de puristes?

Non! Il est vrai que les variables globales sont des pestes Pourquoi ? parce que les fonctions qui utilisent ces globales cessent d'être des entités indépendantes qu'il est possible de considérer intrinséquement en dehors d'un contexte d'utilisation. Au final, cela nuit considérablement à la fiabilité et à la compréhension du code. Il ne faut pas pour autant être sectaire : certaines variables peuvent être de bonnes candidates à ce statut. Mais elles sont très rares, et la question à se poser avant de déclarer une variable globale est : est-ce que c'est nécessaire, utile et logique ! La question: Est-ce que c'est commode ? n'est pas du tout un argument en faveur.

bref, j'ai pas de bonnes raisons mais je trouve pas ça pratique

Pas quand tu auras qq milliers de lignes de code et qq centaines de fonctions, ça je te le garantis

j'ai une unité Constants.h qui contient mes macros et mes définitions de variables globales

Non, un .h ne doit pas contenir la définition de variables. Il est là pour transmettre à toutes les unités de compilation concernées la définition des types que tu as créés et le prototype des fonctions mises à leur disposition

pourquoi ai-je l'impression que je fais n'importe quoi??

Parce que tu te rends compte que c'est bancal

enfin ça marche malgré tout...ce qui est quand même ce qu'on attend de l'appli

Tu te trompes, ce n'est pas le critère principal. L'appli marche (???) tant qu'on a pas trouvé la situation (éventuelle) qui la plante (si elle existe) ce qui peut se produire après des dizaines d'exécution satisfaisante. Le critère majeur est la possibililité pour toi (ou un autre) de comprendre le code des mois plus tard pour le corriger ou l'améliorer

En fait, je disais que ça marchait et que c'était le principal pour me dédouaner d'avoir à refaire un peu d'organisation.

En fait, tu es parfaitement lucide sur les limites que tu apportes toi-même à ton projet par un usage qui peut être abusif de ces "machins"

Ceci étant, j'apprécie beaucoup ton espit (auto) critique
Bonne continuation

[Neilos]

Un exemple très simple contre les variables globales que j'ai utilisé dans un projet pour cause de flémardise.

J'avais quelque chose comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

TStrings *log;

en variable globale.

Et dans une de mes très nombreuses fonction j'utilisais la fonction de math.h....log. --> crash de l'appli.

Les variables globales sont horribles pour le débugage surtout si, comme moi, on ajoute des fonctionnalité une fois l'application finie et qu'on ne se souvient plus de toutes les variables globales.

A prohiber donc...surtout si tu veux économiser quelques heures de débug.

[say]

merci beaucoup pour ces quelques précisions, même si ça m'arrange pas

Et dans une de mes très nombreuses fonction j'utilisais la fonction de math.h....log. --> crash de l'appli.

admettons que ce soit une raison valable, en l'occurence, j'ai établie une convention de nommage qui devrait permettre d'éviter ça.

Tu te trompes, ce n'est pas le critère principal. L'appli marche (???) tant qu'on a pas trouvé la situation (éventuelle) qui la plante (si elle existe) ce qui peut se produire après des dizaines d'exécution satisfaisante. Le critère majeur est la possibililité pour toi (ou un autre) de comprendre le code des mois plus tard pour le corriger ou l'améliorer

tes remarques sont judicieuses, en revanche, je suis pas du tout, mais pas du tout d'accord avec toi. Même si il est primordial que le projet soit lisible, possible à reprendre, etc...etc... le but fondamental d'une application, c'est
sa fonctionnalilté. Ton client il s'en fout de savoir si tu as fait ça proprement, si dans quelques années tu vas galérer, etc...etc...(j'exagère mais c'est pas loin de la vérité).

L'informatique, la programmation n'ont pas de sens propre, seuls leurs objectifs comptent

Ceci dit ça ne m'empêchent pas de commenter le code, et de faire une documentation technique.

C'était une petite parenthèse
je vais détailler un peu plus l'état de mon projet pour comprendre mieux.
je me demandes si je mélange pas plusieurs concepts.

Donc j'ai une Form principal (Form1 par ex).
j'ai un fichier Constants.h, je vais revenir sur ce que j'en fais.
naturellement, j'ai d'autres forms,d 'autres classes à moi.
Justement ces objets sont instanciés une fois pour toute au chargement de l'appli mais doivent être accessibles depuis l'ensemble de l'application donc ils sont définies en extern dans mon fichier Constants.h qui est inclut partout.

Ce fichier définit aussi des macro, des constants, et des variables int auquelles je veux pouvoir accèder sans avoir à instancier un objet.

cependant, si je suis :

parce que les fonctions qui utilisent ces globales cessent d'être des entités indépendantes qu'il est possible de considérer intrinséquement en dehors d'un contexte d'utilisation.

je devrais justement plutot instancié un objet qui me donnerait ces accès?

allez, je me tais...joueur suivant.

Simon

P.S : si je demandes tout ça, c'est justement que je veux faire propre. donc merci d'avance à tous.
pour ce qui est de ce http://www.developpez.net/forums/viewtopic.php?t=421762, pas de suggestions?