Bonjour,
j'ai une classe avec une présentation classique :
- déclarations dans le fichier hpp
- définitions dans le fichier cpp
je me pose la question de la différence entre une variable globale définie
comme suit :
dans cpp :
vector<std::string> x;
et la même chose en tant que membre static private d'une classe
(c'est juste une variable utilisée fréquemment dans certaines méthodes (je
programme un interpréteur))
Dans les deux cas, je ne sais pas comment l'initialiser, excepté dans le
corps du constructeur de la classe qui peut tester si la liste est vide...
Mais je trouve cette solution pas très élégante.
Je veux l'initialiser avec une liste de mots.
est-ce que je peux écrire simplement dans le fichier cpp.
vector<std::string> x;
x.push_back("mot1");
x.push_back("mot2");
etc...
Dans ce cas, quand ce bout de code est exécuté ? (je me pose cette question
parce que ça marche avec mon compilateur, mais que ça me paraît dangeureux
!)
Il y a une raison particuliere qui justifie l'operateur , dans l'initialisation de dummy, plutot qu'un initX() qui retourne un bool ?
Pas vraiment, sinon que dans ce cas-ci, ça tire un peu plus d'attention sur le fait que la valeur d'initialisation n'a aucune signification. (Autre qu'à indiquer que l'initialisation a bien eu lieu.)
-- 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
Michel Decima wrote:
Pareil, évidemment, si l'objet est un membre statique (sauf
qu'il se nomme alors C::x, et non simplement x).
Il y a une raison particuliere qui justifie l'operateur , dans
l'initialisation de dummy, plutot qu'un initX() qui retourne
un bool ?
Pas vraiment, sinon que dans ce cas-ci, ça tire un peu plus
d'attention sur le fait que la valeur d'initialisation n'a
aucune signification. (Autre qu'à indiquer que l'initialisation
a bien eu lieu.)
--
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
Il y a une raison particuliere qui justifie l'operateur , dans l'initialisation de dummy, plutot qu'un initX() qui retourne un bool ?
Pas vraiment, sinon que dans ce cas-ci, ça tire un peu plus d'attention sur le fait que la valeur d'initialisation n'a aucune signification. (Autre qu'à indiquer que l'initialisation a bien eu lieu.)
-- 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
Tu n'as pas oublié static devant std::vector< std::string > x ; ? Ou tu utilises une variable globale.
Je l'utilise plutôt comme une variable globale. Où j'ai mis les static, ce sont des variables qui ne servent qu'à l'initialisation, ici.
Désolé, je comprends pas tout...
Précise ce que tu ne comprends pas, et on essaiera de l'éclairer. Les conceptes en question sont assez simples, mais ils se réposent bien sur des règles C++ qu'on ne connaît pas forcement d'office.
-- 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
Tu n'as pas oublié static devant
std::vector< std::string > x ;
?
Ou tu utilises une variable globale.
Je l'utilise plutôt comme une variable globale. Où j'ai mis les
static, ce sont des variables qui ne servent qu'à
l'initialisation, ici.
Désolé, je comprends pas tout...
Précise ce que tu ne comprends pas, et on essaiera de
l'éclairer. Les conceptes en question sont assez simples, mais
ils se réposent bien sur des règles C++ qu'on ne connaît pas
forcement d'office.
--
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
Tu n'as pas oublié static devant std::vector< std::string > x ; ? Ou tu utilises une variable globale.
Je l'utilise plutôt comme une variable globale. Où j'ai mis les static, ce sont des variables qui ne servent qu'à l'initialisation, ici.
Désolé, je comprends pas tout...
Précise ce que tu ne comprends pas, et on essaiera de l'éclairer. Les conceptes en question sont assez simples, mais ils se réposent bien sur des règles C++ qu'on ne connaît pas forcement d'office.
-- 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
Il y a une raison particuliere qui justifie l'operateur , dans l'initialisation de dummy, plutot qu'un initX() qui retourne un bool ?
Pas vraiment, sinon que dans ce cas-ci, ça tire un peu plus d'attention sur le fait que la valeur d'initialisation n'a aucune signification. (Autre qu'à indiquer que l'initialisation a bien eu lieu.)
Ok, je vois l'idee. J'aurais choisi la version qui retourne un bool pour eviter l'usage de l'operator, qui n'est pas toujours lisible et/ou comprise par la suite, mais ca ne simplifie pas vraiment la comprehension puisque ca deporte le probleme dans initX().
Il y a une raison particuliere qui justifie l'operateur , dans
l'initialisation de dummy, plutot qu'un initX() qui retourne
un bool ?
Pas vraiment, sinon que dans ce cas-ci, ça tire un peu plus
d'attention sur le fait que la valeur d'initialisation n'a
aucune signification. (Autre qu'à indiquer que l'initialisation
a bien eu lieu.)
Ok, je vois l'idee. J'aurais choisi la version qui retourne un bool pour
eviter l'usage de l'operator, qui n'est pas toujours lisible et/ou
comprise par la suite, mais ca ne simplifie pas vraiment la
comprehension puisque ca deporte le probleme dans initX().
Il y a une raison particuliere qui justifie l'operateur , dans l'initialisation de dummy, plutot qu'un initX() qui retourne un bool ?
Pas vraiment, sinon que dans ce cas-ci, ça tire un peu plus d'attention sur le fait que la valeur d'initialisation n'a aucune signification. (Autre qu'à indiquer que l'initialisation a bien eu lieu.)
Ok, je vois l'idee. J'aurais choisi la version qui retourne un bool pour eviter l'usage de l'operator, qui n'est pas toujours lisible et/ou comprise par la suite, mais ca ne simplifie pas vraiment la comprehension puisque ca deporte le probleme dans initX().
Il y a une raison particuliere qui justifie l'operateur , dans l'initialisation de dummy, plutot qu'un initX() qui retourne un bool ?
Pas vraiment, sinon que dans ce cas-ci, ça tire un peu plus d'attention sur le fait que la valeur d'initialisation n'a aucune signification. (Autre qu'à indiquer que l'initialisation a bien eu lieu.)
Ok, je vois l'idee. J'aurais choisi la version qui retourne un bool pour eviter l'usage de l'operator, qui n'est pas toujours lisible et/ou comprise par la suite,
C'est ce que je fais dans la production (où souvent, les règles de codage interdisent l'utilisation de l'operator,()). C'est dans la contexte de la réponse ici que j'ai fait autrement, pour tirer l'attention sur l'idée que la fonction n'était pas là pour sa valeur de retour, mais bien pour ses effets ailleurs.
mais ca ne simplifie pas vraiment la comprehension puisque ca deporte le probleme dans initX().
Quelque soit l'écriture adoptée, un commentaire s'impose.
-- 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
Il y a une raison particuliere qui justifie l'operateur ,
dans l'initialisation de dummy, plutot qu'un initX() qui
retourne un bool ?
Pas vraiment, sinon que dans ce cas-ci, ça tire un peu plus
d'attention sur le fait que la valeur d'initialisation n'a
aucune signification. (Autre qu'à indiquer que
l'initialisation a bien eu lieu.)
Ok, je vois l'idee. J'aurais choisi la version qui retourne un
bool pour eviter l'usage de l'operator, qui n'est pas toujours
lisible et/ou comprise par la suite,
C'est ce que je fais dans la production (où souvent, les règles
de codage interdisent l'utilisation de l'operator,()). C'est
dans la contexte de la réponse ici que j'ai fait autrement, pour
tirer l'attention sur l'idée que la fonction n'était pas là pour
sa valeur de retour, mais bien pour ses effets ailleurs.
mais ca ne simplifie pas
vraiment la comprehension puisque ca deporte le probleme dans
initX().
Quelque soit l'écriture adoptée, un commentaire s'impose.
--
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
Il y a une raison particuliere qui justifie l'operateur , dans l'initialisation de dummy, plutot qu'un initX() qui retourne un bool ?
Pas vraiment, sinon que dans ce cas-ci, ça tire un peu plus d'attention sur le fait que la valeur d'initialisation n'a aucune signification. (Autre qu'à indiquer que l'initialisation a bien eu lieu.)
Ok, je vois l'idee. J'aurais choisi la version qui retourne un bool pour eviter l'usage de l'operator, qui n'est pas toujours lisible et/ou comprise par la suite,
C'est ce que je fais dans la production (où souvent, les règles de codage interdisent l'utilisation de l'operator,()). C'est dans la contexte de la réponse ici que j'ai fait autrement, pour tirer l'attention sur l'idée que la fonction n'était pas là pour sa valeur de retour, mais bien pour ses effets ailleurs.
mais ca ne simplifie pas vraiment la comprehension puisque ca deporte le probleme dans initX().
Quelque soit l'écriture adoptée, un commentaire s'impose.
-- 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
