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.
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 declarant ta variable dans le .h elle sera définie dans chaque fichier .cpp compilé en .o
Il faut définir ta var globale en "extern" dans ton fichier .h et la definir normalement dans 1 SEUL FICHIER .cpp !
http://www.debugbar.com : The most advanced WEB development tool for Internet Explorer http://www.core-services.fr - {Enjoy the future today}
Pascal wrote:
Bonjour,
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 declarant ta variable dans le .h elle sera définie dans chaque
fichier .cpp compilé en .o
Il faut définir ta var globale en "extern" dans ton fichier .h et la
definir normalement dans 1 SEUL FICHIER .cpp !
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 declarant ta variable dans le .h elle sera définie dans chaque fichier .cpp compilé en .o
Il faut définir ta var globale en "extern" dans ton fichier .h et la definir normalement dans 1 SEUL FICHIER .cpp !
http://www.debugbar.com : The most advanced WEB development tool for Internet Explorer http://www.core-services.fr - {Enjoy the future today}
korchkidu
Pascal wrote:
Bonjour,
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. Sauf erreur, si tu inclues plusieurs fois ton fichier, tu auras
plusieurs fois la variable varglobale de declaree. En plus, les variables globales c'est mal, c'est le diable. 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. Ca a le merite de m'eviter de faire des aneries...enfin en tout cas, pour ca...;))
K.
Pascal wrote:
Bonjour,
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.
Sauf erreur, si tu inclues plusieurs fois ton fichier, tu auras
plusieurs fois la variable varglobale de declaree. En plus, les
variables globales c'est mal, c'est le diable. 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. Ca a le merite de m'eviter de faire des
aneries...enfin en tout cas, pour ca...;))
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. Sauf erreur, si tu inclues plusieurs fois ton fichier, tu auras
plusieurs fois la variable varglobale de declaree. En plus, les variables globales c'est mal, c'est le diable. 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. Ca a le merite de m'eviter de faire des aneries...enfin en tout cas, pour ca...;))
K.
Pascal
On Tue, 22 Feb 2005 18:20:21 +0100, Jean-Fabrice RABAUTE wrote:
En declarant ta variable dans le .h elle sera définie dans chaque fichier .cpp compilé en .o
Il faut définir ta var globale en "extern" dans ton fichier .h et la definir normalement dans 1 SEUL FICHIER .cpp !
Donc dans ton .h :
extern int varglobale;
Dans 1 SEUL DE TES .CPP :
int varglobale;
Voila. Ca devrait le faire.
A+
Salut,
Merci beaucoup, ça marche impeccable.
On Tue, 22 Feb 2005 18:20:21 +0100, Jean-Fabrice RABAUTE wrote:
En declarant ta variable dans le .h elle sera définie dans chaque
fichier .cpp compilé en .o
Il faut définir ta var globale en "extern" dans ton fichier .h et la
definir normalement dans 1 SEUL FICHIER .cpp !
On Tue, 22 Feb 2005 18:20:21 +0100, Jean-Fabrice RABAUTE wrote:
En declarant ta variable dans le .h elle sera définie dans chaque fichier .cpp compilé en .o
Il faut définir ta var globale en "extern" dans ton fichier .h et la definir normalement dans 1 SEUL FICHIER .cpp !
Donc dans ton .h :
extern int varglobale;
Dans 1 SEUL DE TES .CPP :
int varglobale;
Voila. Ca devrait le faire.
A+
Salut,
Merci beaucoup, ça marche impeccable.
Pascal
On Tue, 22 Feb 2005 18:25:55 +0100, korchkidu wrote:
Sauf erreur, si tu inclues plusieurs fois ton fichier, tu auras plusieurs fois la variable varglobale de declaree. En plus, les variables globales c'est mal, c'est le diable. 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. Ca a le merite de m'eviter de faire des aneries...enfin en tout cas, pour ca...;))
K.
J'ai voulu le mettre en static, mais il me mettait variable undefined ... Dans ma classe Truc, j'ai défini : class Truc { public: static int machin; ... }
Puis dans le .cpp d'une autre classe, j'avais fait un include de Truc.h, et lorsque j'appelais Truc::machin, il me mettait variable undefined.
On Tue, 22 Feb 2005 18:25:55 +0100, korchkidu wrote:
Sauf erreur, si tu inclues plusieurs fois ton fichier, tu auras
plusieurs fois la variable varglobale de declaree. En plus, les
variables globales c'est mal, c'est le diable. 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. Ca a le merite de m'eviter de faire des
aneries...enfin en tout cas, pour ca...;))
K.
J'ai voulu le mettre en static, mais il me mettait variable undefined ...
Dans ma classe Truc, j'ai défini :
class Truc {
public:
static int machin;
...
}
Puis dans le .cpp d'une autre classe, j'avais fait un include de Truc.h,
et lorsque j'appelais Truc::machin, il me mettait variable undefined.
On Tue, 22 Feb 2005 18:25:55 +0100, korchkidu wrote:
Sauf erreur, si tu inclues plusieurs fois ton fichier, tu auras plusieurs fois la variable varglobale de declaree. En plus, les variables globales c'est mal, c'est le diable. 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. Ca a le merite de m'eviter de faire des aneries...enfin en tout cas, pour ca...;))
K.
J'ai voulu le mettre en static, mais il me mettait variable undefined ... Dans ma classe Truc, j'ai défini : class Truc { public: static int machin; ... }
Puis dans le .cpp d'une autre classe, j'avais fait un include de Truc.h, et lorsque j'appelais Truc::machin, il me mettait variable undefined.
korchkidu
Pascal wrote:
On Tue, 22 Feb 2005 18:25:55 +0100, korchkidu wrote:
Sauf erreur, si tu inclues plusieurs fois ton fichier, tu auras plusieurs fois la variable varglobale de declaree. En plus, les variables globales c'est mal, c'est le diable. 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. Ca a le merite de m'eviter de faire des aneries...enfin en tout cas, pour ca...;))
K.
J'ai voulu le mettre en static, mais il me mettait variable undefined ... Dans ma classe Truc, j'ai défini : class Truc { public: static int machin; ... }
Puis dans le .cpp d'une autre classe, j'avais fait un include de Truc.h, et lorsque j'appelais Truc::machin, il me mettait variable undefined. Dans le cpp il faut que tu la definisses. Tu l'initialises a une valeur
qui va bien:
Truc::mavarglobale = 0.;
par exemple.
K.
Pascal wrote:
On Tue, 22 Feb 2005 18:25:55 +0100, korchkidu wrote:
Sauf erreur, si tu inclues plusieurs fois ton fichier, tu auras
plusieurs fois la variable varglobale de declaree. En plus, les
variables globales c'est mal, c'est le diable. 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. Ca a le merite de m'eviter de faire des
aneries...enfin en tout cas, pour ca...;))
K.
J'ai voulu le mettre en static, mais il me mettait variable undefined ...
Dans ma classe Truc, j'ai défini :
class Truc {
public:
static int machin;
...
}
Puis dans le .cpp d'une autre classe, j'avais fait un include de Truc.h,
et lorsque j'appelais Truc::machin, il me mettait variable undefined.
Dans le cpp il faut que tu la definisses. Tu l'initialises a une valeur
On Tue, 22 Feb 2005 18:25:55 +0100, korchkidu wrote:
Sauf erreur, si tu inclues plusieurs fois ton fichier, tu auras plusieurs fois la variable varglobale de declaree. En plus, les variables globales c'est mal, c'est le diable. 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. Ca a le merite de m'eviter de faire des aneries...enfin en tout cas, pour ca...;))
K.
J'ai voulu le mettre en static, mais il me mettait variable undefined ... Dans ma classe Truc, j'ai défini : class Truc { public: static int machin; ... }
Puis dans le .cpp d'une autre classe, j'avais fait un include de Truc.h, et lorsque j'appelais Truc::machin, il me mettait variable undefined. Dans le cpp il faut que tu la definisses. Tu l'initialises a une valeur
qui va bien:
Truc::mavarglobale = 0.;
par exemple.
K.
Loïc Joly
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 ?
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 ?
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.
(*) Sur un compilateur ne supportant pas les namespaces, je pourrais encore admettre un avantage que ça permet de les simuler en partie, mais qui à part James ici a connu ce genre de compilateur... ;)
-- Loïc
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 ?
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 ?
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.
(*) Sur un compilateur ne supportant pas les namespaces, je pourrais
encore admettre un avantage que ça permet de les simuler en partie, mais
qui à part James ici a connu ce genre de compilateur... ;)
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 ?
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 ?
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.
(*) Sur un compilateur ne supportant pas les namespaces, je pourrais encore admettre un avantage que ça permet de les simuler en partie, mais qui à part James ici a connu ce genre de compilateur... ;)
-- Loïc
korchkidu
Loïc Joly wrote:
Ah bon ? Et ma place au Walhalla/Champs Elysées est-elle compromise si j'utilise cin et cout ? Si tu te confesses avant, on pourra toujours negocier...;)
Et quelle est la différence avec une variable globale ?
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. Ben pour moi, le principal inconvenient des variables globales, c'est
que l'on peut facilement s'emmeler les pinceaux en la modifiant sans le vouloir...(ce qui revient a peu pres a ton premier point). Par contre, si tu ecris Common::mavariable, ca diminue les risques qd meme (hors raisons metaphysiques bien evidemment...).
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é. Par contre la serieusement, je ne te suis plus. Qu'est ce que ca peut
poser comme probleme ce genre de....problemes? (je precise que c'est une vraie question..)
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. La lisibilite?
(*) Sur un compilateur ne supportant pas les namespaces, je pourrais encore admettre un avantage que ça permet de les simuler en partie, mais qui à part James ici a connu ce genre de compilateur... ;) Desole, je suis trop jeune, je n'ai jamais programme sur des cartes a
trous...:D
K.
Loïc Joly wrote:
Ah bon ? Et ma place au Walhalla/Champs Elysées est-elle compromise si
j'utilise cin et cout ?
Si tu te confesses avant, on pourra toujours negocier...;)
Et quelle est la différence avec une variable globale ?
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.
Ben pour moi, le principal inconvenient des variables globales, c'est
que l'on peut facilement s'emmeler les pinceaux en la modifiant sans le
vouloir...(ce qui revient a peu pres a ton premier point). Par contre,
si tu ecris Common::mavariable, ca diminue les risques qd meme (hors
raisons metaphysiques bien evidemment...).
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é.
Par contre la serieusement, je ne te suis plus. Qu'est ce que ca peut
poser comme probleme ce genre de....problemes? (je precise que c'est une
vraie question..)
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.
La lisibilite?
(*) Sur un compilateur ne supportant pas les namespaces, je pourrais
encore admettre un avantage que ça permet de les simuler en partie, mais
qui à part James ici a connu ce genre de compilateur... ;)
Desole, je suis trop jeune, je n'ai jamais programme sur des cartes a
Ah bon ? Et ma place au Walhalla/Champs Elysées est-elle compromise si j'utilise cin et cout ? Si tu te confesses avant, on pourra toujours negocier...;)
Et quelle est la différence avec une variable globale ?
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. Ben pour moi, le principal inconvenient des variables globales, c'est
que l'on peut facilement s'emmeler les pinceaux en la modifiant sans le vouloir...(ce qui revient a peu pres a ton premier point). Par contre, si tu ecris Common::mavariable, ca diminue les risques qd meme (hors raisons metaphysiques bien evidemment...).
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é. Par contre la serieusement, je ne te suis plus. Qu'est ce que ca peut
poser comme probleme ce genre de....problemes? (je precise que c'est une vraie question..)
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. La lisibilite?
(*) Sur un compilateur ne supportant pas les namespaces, je pourrais encore admettre un avantage que ça permet de les simuler en partie, mais qui à part James ici a connu ce genre de compilateur... ;) Desole, je suis trop jeune, je n'ai jamais programme sur des cartes a
trous...:D
K.
Pascal
korchkidu wrote:
Ben pour moi, le principal inconvenient des variables globales, c'est que l'on peut facilement s'emmeler les pinceaux en la modifiant sans le vouloir...(ce qui revient a peu pres a ton premier point). Par contre, si tu ecris Common::mavariable, ca diminue les risques qd meme (hors raisons metaphysiques bien evidemment...).
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. Or certaine variable ne font partie d'aucune classe. 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. 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.
La lisibilite?
Au détriment de la cohérence?
-- Pascal
korchkidu wrote:
Ben pour moi, le principal inconvenient des variables globales, c'est
que l'on peut facilement s'emmeler les pinceaux en la modifiant sans le
vouloir...(ce qui revient a peu pres a ton premier point). Par contre,
si tu ecris Common::mavariable, ca diminue les risques qd meme (hors
raisons metaphysiques bien evidemment...).
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. Or certaine variable ne
font partie d'aucune classe. 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. 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.
Ben pour moi, le principal inconvenient des variables globales, c'est que l'on peut facilement s'emmeler les pinceaux en la modifiant sans le vouloir...(ce qui revient a peu pres a ton premier point). Par contre, si tu ecris Common::mavariable, ca diminue les risques qd meme (hors raisons metaphysiques bien evidemment...).
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. Or certaine variable ne font partie d'aucune classe. 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. 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.
La lisibilite?
Au détriment de la cohérence?
-- Pascal
Pascal
Loïc Joly wrote:
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.
Une variable static aussi. Et pour moi ce que tu cites n'est pas un inconvénient, mais son principal avantage. C'est là toute l'intérêt de ce genre de variable.
(*) Sur un compilateur ne supportant pas les namespaces, je pourrais encore admettre un avantage que ça permet de les simuler en partie, mais qui à part James ici a connu ce genre de compilateur... ;)
Effectivment.
-- Pascal
Loïc Joly wrote:
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.
Une variable static aussi. Et pour moi ce que tu cites n'est pas un
inconvénient, mais son principal avantage. C'est là toute l'intérêt de
ce genre de variable.
(*) Sur un compilateur ne supportant pas les namespaces, je pourrais
encore admettre un avantage que ça permet de les simuler en partie, mais
qui à part James ici a connu ce genre de compilateur... ;)
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.
Une variable static aussi. Et pour moi ce que tu cites n'est pas un inconvénient, mais son principal avantage. C'est là toute l'intérêt de ce genre de variable.
(*) Sur un compilateur ne supportant pas les namespaces, je pourrais encore admettre un avantage que ça permet de les simuler en partie, mais qui à part James ici a connu ce genre de compilateur... ;)
Effectivment.
-- Pascal
Loïc Joly
korchkidu wrote:
Loïc Joly wrote:
Ah bon ? Et ma place au Walhalla/Champs Elysées est-elle compromise si j'utilise cin et cout ?
Si tu te confesses avant, on pourra toujours negocier...;)
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 ?
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é.
Par contre la serieusement, je ne te suis plus. Qu'est ce que ca peut poser comme probleme ce genre de....problemes? (je precise que c'est une vraie question..)
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.
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.
La lisibilite?
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.
(*) Sur un compilateur ne supportant pas les namespaces, je pourrais encore admettre un avantage que ça permet de les simuler en partie, mais qui à part James ici a connu ce genre de compilateur... ;)
Desole, je suis trop jeune, je n'ai jamais programme sur des cartes a trous...:D
Pourtant, ton argument ne s'appliquerait pleinement que si c'était le cas.
-- Loïc
korchkidu wrote:
Loïc Joly wrote:
Ah bon ? Et ma place au Walhalla/Champs Elysées est-elle compromise si
j'utilise cin et cout ?
Si tu te confesses avant, on pourra toujours negocier...;)
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 ?
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é.
Par contre la serieusement, je ne te suis plus. Qu'est ce que ca peut
poser comme probleme ce genre de....problemes? (je precise que c'est une
vraie question..)
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.
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.
La lisibilite?
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.
(*) Sur un compilateur ne supportant pas les namespaces, je pourrais
encore admettre un avantage que ça permet de les simuler en partie,
mais qui à part James ici a connu ce genre de compilateur... ;)
Desole, je suis trop jeune, je n'ai jamais programme sur des cartes a
trous...:D
Pourtant, ton argument ne s'appliquerait pleinement que si c'était le cas.
Ah bon ? Et ma place au Walhalla/Champs Elysées est-elle compromise si j'utilise cin et cout ?
Si tu te confesses avant, on pourra toujours negocier...;)
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 ?
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é.
Par contre la serieusement, je ne te suis plus. Qu'est ce que ca peut poser comme probleme ce genre de....problemes? (je precise que c'est une vraie question..)
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.
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.
La lisibilite?
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.
(*) Sur un compilateur ne supportant pas les namespaces, je pourrais encore admettre un avantage que ça permet de les simuler en partie, mais qui à part James ici a connu ce genre de compilateur... ;)
Desole, je suis trop jeune, je n'ai jamais programme sur des cartes a trous...:D
Pourtant, ton argument ne s'appliquerait pleinement que si c'était le cas.
