J'ai besoin d'une variable globale, et je ne sais pas la déclaré.
Dans mon fichier Interface.h, qui contient la classe Interface, j'ai
déclaré une variable globale comme suit:
int varglobale;
#ifndef INTERFACE
#define INTERFACE
class Interface { ... };
#endif
Le problème, c'est qu'à la compilation je me retrouve avec cette erreur:
Interface.o(.bss+0x4):/usr/lib/gcc-lib/i586-pc-linux-gnu/3.2.2/include/g++-v3/bits/stl_tree.h:194: multiple definition of `g_TAILLEPAGE'
GestionnaireMV.o(.bss+0x0):/export/home/05gmi3/teapa5/projet/SGBD/GestionnaireMV.cpp:8: first defined here
Et dans mon fichier GestionnaireMV.cpp, j'ai fait un #include
"Interface.h"
D'où vient le pb? ça fait un moment que je cherche en vain.
En plus, les variables globales c'est mal, c'est le diable.
Ah bon ? Et ma place au Walhalla/Champs Elysées est-elle compromise si j'utilise cin et cout ?
Certainement. Quant à cerr, en revanche... :-)
Perso, moi je prefere faire une classe ou je mets mes variables globales comme membres statiques (je sais pas si c'est une bonne idee mais c'est pratique en tout cas...;)).
Et quelle est la différence avec une variable globale ?
La risque que quelqu'un d'autre en modifie la valeur de façon inopinément. La risque de conflit de nom est moindre avec la classe, aussi ; aujourd'hui, il y a des espaces référentiels, ce n'est que très récemment qu'on pourrait s'en servir dans du code portable. (J'ai eu des problèmes avec une utilisation dans VC++ 6.0. Je ne sais pas d'où venait le problème, mais j'ai ôté les namespaces du projet, et ça a marché. Or, VC++ 6.0 sert encore dans beaucoup d'endroits.)
Pour moi, le principal inconvénient (hors raisons métaphysiques) des variables globales, c'est que potentiellement n'importe quelle fonction peut la modifier n'importe quand, ce qui brise toute encapsulation et si rend l'écriture de tout test unitaire un peu sérieux pratiquement impossible.
Un autre inconvénient, moindre, et que l'ordre de création de variables globales définies dans des unités de compilation différentes est non spécifié.
Dans les deux cas, ta solution n'apporte pas vraiment de solution, et je ne vois pas en quoi c'est préférable(*) par rapport à de simples variables globales.
Pour le premier inconvénient, rendre la variable membre privée d'une classe apporte beaucoup.
La vrai question, c'est qui doit se servir de la variable.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Loïc Joly wrote:
korchkidu wrote:
En plus, les variables globales c'est mal, c'est le diable.
Ah bon ? Et ma place au Walhalla/Champs Elysées est-elle
compromise si j'utilise cin et cout ?
Certainement. Quant à cerr, en revanche... :-)
Perso, moi je prefere faire une classe ou je mets mes
variables globales comme membres statiques (je sais pas si
c'est une bonne idee mais c'est pratique en tout cas...;)).
Et quelle est la différence avec une variable globale ?
La risque que quelqu'un d'autre en modifie la valeur de façon
inopinément. La risque de conflit de nom est moindre avec la
classe, aussi ; aujourd'hui, il y a des espaces référentiels, ce
n'est que très récemment qu'on pourrait s'en servir dans du code
portable. (J'ai eu des problèmes avec une utilisation dans VC++
6.0. Je ne sais pas d'où venait le problème, mais j'ai ôté les
namespaces du projet, et ça a marché. Or, VC++ 6.0 sert encore
dans beaucoup d'endroits.)
Pour moi, le principal inconvénient (hors raisons
métaphysiques) des variables globales, c'est que
potentiellement n'importe quelle fonction peut la modifier
n'importe quand, ce qui brise toute encapsulation et si rend
l'écriture de tout test unitaire un peu sérieux pratiquement
impossible.
Un autre inconvénient, moindre, et que l'ordre de création de
variables globales définies dans des unités de compilation
différentes est non spécifié.
Dans les deux cas, ta solution n'apporte pas vraiment de
solution, et je ne vois pas en quoi c'est préférable(*) par
rapport à de simples variables globales.
Pour le premier inconvénient, rendre la variable membre privée
d'une classe apporte beaucoup.
La vrai question, c'est qui doit se servir de la variable.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
En plus, les variables globales c'est mal, c'est le diable.
Ah bon ? Et ma place au Walhalla/Champs Elysées est-elle compromise si j'utilise cin et cout ?
Certainement. Quant à cerr, en revanche... :-)
Perso, moi je prefere faire une classe ou je mets mes variables globales comme membres statiques (je sais pas si c'est une bonne idee mais c'est pratique en tout cas...;)).
Et quelle est la différence avec une variable globale ?
La risque que quelqu'un d'autre en modifie la valeur de façon inopinément. La risque de conflit de nom est moindre avec la classe, aussi ; aujourd'hui, il y a des espaces référentiels, ce n'est que très récemment qu'on pourrait s'en servir dans du code portable. (J'ai eu des problèmes avec une utilisation dans VC++ 6.0. Je ne sais pas d'où venait le problème, mais j'ai ôté les namespaces du projet, et ça a marché. Or, VC++ 6.0 sert encore dans beaucoup d'endroits.)
Pour moi, le principal inconvénient (hors raisons métaphysiques) des variables globales, c'est que potentiellement n'importe quelle fonction peut la modifier n'importe quand, ce qui brise toute encapsulation et si rend l'écriture de tout test unitaire un peu sérieux pratiquement impossible.
Un autre inconvénient, moindre, et que l'ordre de création de variables globales définies dans des unités de compilation différentes est non spécifié.
Dans les deux cas, ta solution n'apporte pas vraiment de solution, et je ne vois pas en quoi c'est préférable(*) par rapport à de simples variables globales.
Pour le premier inconvénient, rendre la variable membre privée d'une classe apporte beaucoup.
La vrai question, c'est qui doit se servir de la variable.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
korchkidu
Pascal wrote:
korchkidu wrote:
Je suis pas du tout d'accord. Mettre une variable static n'a de sens que si la variable est bien un membre de la classe. Bah si ma classe est justement faite pour "recevoir" les variables
globales...
Or certaine variable ne font partie d'aucune classe. Si elles sont globales, alors elles font parties de ma classe faite
specialement pour...
Moi je ne trouve pas ça correct de le mettre dans une classe, et le mettre en static, juste pour ne pas avoir une variable globale. Mais ce n'est pas UNE classe, mais LA classe...;)) Pas taper...
Ensuite je ne comprends pas ton argumentation. Comment tu fais pour modif une variable globale sans t'en rendre compte? Un exemple pour illustrer ton propos serait le bienvenu. #include <iostream>
int i = 4;
int plus1(int i);
int main(void) { int i = 20;
i = plus1(i); std::cout<<"Le resultat du programme est: "<<i<<std::endl;
return 0; }
int plus1(int j) { return ++i; }
Quand tu sais deja quel est le probleme ca aide, qd tu relis ca, c'est plus difficile. (Ce code est tire d'une histoire vraie...)
La lisibilite?
Au détriment de la cohérence? Quelle est l'incoherence la dedans?
De plus, si un jour tu as besoin de beaucoup de variables globales, tu verras assez vite que la possibilite de les voir du premier coup d'oeil fait gagner un temps non-negligeable.
K.
Pascal wrote:
korchkidu wrote:
Je suis pas du tout d'accord. Mettre une variable static n'a de sens que
si la variable est bien un membre de la classe.
Bah si ma classe est justement faite pour "recevoir" les variables
globales...
Or certaine variable ne
font partie d'aucune classe.
Si elles sont globales, alors elles font parties de ma classe faite
specialement pour...
Moi je ne trouve pas ça correct de le
mettre dans une classe, et le mettre en static, juste pour ne pas avoir
une variable globale.
Mais ce n'est pas UNE classe, mais LA classe...;)) Pas taper...
Ensuite je ne comprends pas ton argumentation.
Comment tu fais pour modif une variable globale sans t'en rendre compte?
Un exemple pour illustrer ton propos serait le bienvenu.
#include <iostream>
int i = 4;
int plus1(int i);
int main(void)
{
int i = 20;
i = plus1(i);
std::cout<<"Le resultat du programme est: "<<i<<std::endl;
return 0;
}
int plus1(int j)
{
return ++i;
}
Quand tu sais deja quel est le probleme ca aide, qd tu relis ca, c'est
plus difficile.
(Ce code est tire d'une histoire vraie...)
La lisibilite?
Au détriment de la cohérence?
Quelle est l'incoherence la dedans?
De plus, si un jour tu as besoin de beaucoup de variables globales, tu
verras assez vite que la possibilite de les voir du premier coup d'oeil
fait gagner un temps non-negligeable.
Je suis pas du tout d'accord. Mettre une variable static n'a de sens que si la variable est bien un membre de la classe. Bah si ma classe est justement faite pour "recevoir" les variables
globales...
Or certaine variable ne font partie d'aucune classe. Si elles sont globales, alors elles font parties de ma classe faite
specialement pour...
Moi je ne trouve pas ça correct de le mettre dans une classe, et le mettre en static, juste pour ne pas avoir une variable globale. Mais ce n'est pas UNE classe, mais LA classe...;)) Pas taper...
Ensuite je ne comprends pas ton argumentation. Comment tu fais pour modif une variable globale sans t'en rendre compte? Un exemple pour illustrer ton propos serait le bienvenu. #include <iostream>
int i = 4;
int plus1(int i);
int main(void) { int i = 20;
i = plus1(i); std::cout<<"Le resultat du programme est: "<<i<<std::endl;
return 0; }
int plus1(int j) { return ++i; }
Quand tu sais deja quel est le probleme ca aide, qd tu relis ca, c'est plus difficile. (Ce code est tire d'une histoire vraie...)
La lisibilite?
Au détriment de la cohérence? Quelle est l'incoherence la dedans?
De plus, si un jour tu as besoin de beaucoup de variables globales, tu verras assez vite que la possibilite de les voir du premier coup d'oeil fait gagner un temps non-negligeable.
K.
korchkidu
Loïc Joly wrote:
korchkidu wrote:
Ah, c'est dans ce sens que ça marche ? Mon père, je vais pêcher, torture, violer,... pendant les deux prochaines décénies, pourriez vous me confesser par avance ? On m'aurait menti??...:D
Ca expliquerait bien des choses....
Deux variables globales a et b de type A et B définies dans deux unités de compilation différentes. Dans le constructeur de A, on fait appel à l'objet b. Pourtant on n'est pas sur qu'au moment où on crée a, b soit déjà crée.
Ca arrive en fait relativement souvent. Oui, oui. C'est tout de suite plus clair avec un exemple.
Mouaip, le fait de pouvoir faire une recherche textuelle facilement sur toutes les utilisations des variables globales est un plus, mais je pense qu'on fait tout aussi bien en mettant ces variables dans un namespace (qui a aussi l'avantage de pouvoir être extensible...) qu'en en faisant des variables statiques de classe. C'est ce que j'avais fait au debut effectivement. Je devais en plus
rajouter un traitement sur mes variables globales dans certaines condition alors j'ai mis ca dans une classe finalement. Je suis sur qu'en fouillant la conception, ya moyen de faire plus propre mais je n'avais franchement pas le courage de tout casser...
K.
Loïc Joly wrote:
korchkidu wrote:
Ah, c'est dans ce sens que ça marche ? Mon père, je vais pêcher,
torture, violer,... pendant les deux prochaines décénies, pourriez vous
me confesser par avance ?
On m'aurait menti??...:D
Ca expliquerait bien des choses....
Deux variables globales a et b de type A et B définies dans deux unités
de compilation différentes. Dans le constructeur de A, on fait appel à
l'objet b. Pourtant on n'est pas sur qu'au moment où on crée a, b soit
déjà crée.
Ca arrive en fait relativement souvent.
Oui, oui. C'est tout de suite plus clair avec un exemple.
Mouaip, le fait de pouvoir faire une recherche textuelle facilement sur
toutes les utilisations des variables globales est un plus, mais je
pense qu'on fait tout aussi bien en mettant ces variables dans un
namespace (qui a aussi l'avantage de pouvoir être extensible...) qu'en
en faisant des variables statiques de classe.
C'est ce que j'avais fait au debut effectivement. Je devais en plus
rajouter un traitement sur mes variables globales dans certaines
condition alors j'ai mis ca dans une classe finalement. Je suis sur
qu'en fouillant la conception, ya moyen de faire plus propre mais je
n'avais franchement pas le courage de tout casser...
Ah, c'est dans ce sens que ça marche ? Mon père, je vais pêcher, torture, violer,... pendant les deux prochaines décénies, pourriez vous me confesser par avance ? On m'aurait menti??...:D
Ca expliquerait bien des choses....
Deux variables globales a et b de type A et B définies dans deux unités de compilation différentes. Dans le constructeur de A, on fait appel à l'objet b. Pourtant on n'est pas sur qu'au moment où on crée a, b soit déjà crée.
Ca arrive en fait relativement souvent. Oui, oui. C'est tout de suite plus clair avec un exemple.
Mouaip, le fait de pouvoir faire une recherche textuelle facilement sur toutes les utilisations des variables globales est un plus, mais je pense qu'on fait tout aussi bien en mettant ces variables dans un namespace (qui a aussi l'avantage de pouvoir être extensible...) qu'en en faisant des variables statiques de classe. C'est ce que j'avais fait au debut effectivement. Je devais en plus
rajouter un traitement sur mes variables globales dans certaines condition alors j'ai mis ca dans une classe finalement. Je suis sur qu'en fouillant la conception, ya moyen de faire plus propre mais je n'avais franchement pas le courage de tout casser...
K.
lerouzic
korchkidu wrote in message
Perso, moi je prefere faire une classe ou je mets mes variables globales comme membres statiques (je sais pas si c'est une bonne idee mais c'est pratique en tout cas...;)). Comme ca, dans mon code j'ai des trucs du genre Common::mavarglobale.
Je ne sais pas du tout si c'est une solution courante, mais j'utilise une variante de la "classe à variables globales". Souvent, ces variables globales ne sont pas utilisées par toutes les classes, mais plutôt par des classes qui n'ont rien à voir les unes avec les autres. Dans ce cas, je fais quelque chose comme :
class Variables { protected : static int var1; };
class BesoinDeVar1 : public Variables { // ... ici, on peut utiliser var1 comme une variable membre };
class PasBesoinDeVar1 { // ici, rien à faire, var1 est inconnue au bataillon };
Ca me semble préserver l'encapsulation, il n'y a plus vraiment de variables globale, mais var1 peut être utilisée à peu près n'importe où, dans les classes qui doivent y avoir accès.
korchkidu <korch_ki_du@yahoo.fr> wrote in message
Perso, moi je prefere
faire une classe ou je mets mes variables globales comme membres
statiques (je sais pas si c'est une bonne idee mais c'est pratique en
tout cas...;)). Comme ca, dans mon code j'ai des trucs du genre
Common::mavarglobale.
Je ne sais pas du tout si c'est une solution courante, mais j'utilise
une variante de la "classe à variables globales". Souvent, ces
variables globales ne sont pas utilisées par toutes les classes, mais
plutôt par des classes qui n'ont rien à voir les unes avec les autres.
Dans ce cas, je fais quelque chose comme :
class Variables
{ protected : static int var1; };
class BesoinDeVar1 : public Variables
{
// ... ici, on peut utiliser var1 comme une variable membre
};
class PasBesoinDeVar1
{
// ici, rien à faire, var1 est inconnue au bataillon
};
Ca me semble préserver l'encapsulation, il n'y a plus vraiment de
variables globale, mais var1 peut être utilisée à peu près n'importe
où, dans les classes qui doivent y avoir accès.
Perso, moi je prefere faire une classe ou je mets mes variables globales comme membres statiques (je sais pas si c'est une bonne idee mais c'est pratique en tout cas...;)). Comme ca, dans mon code j'ai des trucs du genre Common::mavarglobale.
Je ne sais pas du tout si c'est une solution courante, mais j'utilise une variante de la "classe à variables globales". Souvent, ces variables globales ne sont pas utilisées par toutes les classes, mais plutôt par des classes qui n'ont rien à voir les unes avec les autres. Dans ce cas, je fais quelque chose comme :
class Variables { protected : static int var1; };
class BesoinDeVar1 : public Variables { // ... ici, on peut utiliser var1 comme une variable membre };
class PasBesoinDeVar1 { // ici, rien à faire, var1 est inconnue au bataillon };
Ca me semble préserver l'encapsulation, il n'y a plus vraiment de variables globale, mais var1 peut être utilisée à peu près n'importe où, dans les classes qui doivent y avoir accès.
Michel Michaud
Dans le message ,
J'ai besoin d'une variable globale, et je ne sais pas la déclaré.
Comme personne ne l'a fait, je me permets de remettre dans la discussion les fonctions de style singleton, qu'on pourrait mettre dans un namespace ou une classe au besoin :
Au lieu de :
int varglobale;
On met simplement ceci directement quelque part :
int& VarGlobale() // En inline si dans fichier d'en-tête { static int laValeur; return laValeur; }
Il devient alors facile de voir qui modifie cette variable en mettant une trace quelconque dans la fonction...
Il n'y a plus de raison intéressante pour utiliser de vraies variables globales (sauf un compilateur trop ancien, mais dans ce cas, j'ai commencé à me dire que ce n'est pas du C++ qu'on fait, mais bien un de ses dialectes...)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans le message pan.2005.02.22.17.09.45.470673@B022-05.fr,
J'ai besoin d'une variable globale, et je ne sais pas la déclaré.
Comme personne ne l'a fait, je me permets de remettre dans la
discussion les fonctions de style singleton, qu'on pourrait mettre
dans un namespace ou une classe au besoin :
Au lieu de :
int varglobale;
On met simplement ceci directement quelque part :
int& VarGlobale() // En inline si dans fichier d'en-tête
{
static int laValeur;
return laValeur;
}
Il devient alors facile de voir qui modifie cette variable en
mettant une trace quelconque dans la fonction...
Il n'y a plus de raison intéressante pour utiliser de vraies
variables globales (sauf un compilateur trop ancien, mais dans ce
cas, j'ai commencé à me dire que ce n'est pas du C++ qu'on fait,
mais bien un de ses dialectes...)
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
J'ai besoin d'une variable globale, et je ne sais pas la déclaré.
Comme personne ne l'a fait, je me permets de remettre dans la discussion les fonctions de style singleton, qu'on pourrait mettre dans un namespace ou une classe au besoin :
Au lieu de :
int varglobale;
On met simplement ceci directement quelque part :
int& VarGlobale() // En inline si dans fichier d'en-tête { static int laValeur; return laValeur; }
Il devient alors facile de voir qui modifie cette variable en mettant une trace quelconque dans la fonction...
Il n'y a plus de raison intéressante pour utiliser de vraies variables globales (sauf un compilateur trop ancien, mais dans ce cas, j'ai commencé à me dire que ce n'est pas du C++ qu'on fait, mais bien un de ses dialectes...)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
