d�clarer un string a partir d'une variable

Bonjour,

Je d�sire d�clarer une suite de variables, dont le dernier caract�re du nom est incr�ment�.

Par exemple :

Code:

---

1 2 3 4

ucstring variable1; ucstring variable2; ucstring variable3; ...

---

Pour cela je concat�ne deux string :

Code:

---

1 2 3 4 5 6 7 8 9 10

int NombreDeVariable = 5; int i = 0;   while (i<NombreDeVariable) { ucstring j.fromUtf8(i); // Converti int en ucstring ucstring test = "variable"; ucstring variable = test += j; // Concatenation i++;}

---

variable prend donc les valeurs : "variable1, variable2,...".
Le probl�me est que je ne sais pas comment d�clarer une variable qui � pour nom (et non pas pour valeur) "variable1, variable2,...".

En gros, tu ne peux pas. Les noms de variables cela rel�ve du code source, et ca disparait � l'ex�cution. Maintenant, tu peux faire un tableau de variables, genre

string variables[5];
ou
vector<string> variables;

que tu acc�deras par leur indice.
variables[0] �tant ce que tu voulais appeler variable1 (seule diff�rence, les tableaux C et C++ sont en base z�ro, mais tu peux aussi faire un tableau plus long d'une variable, et ne pas utiliser variables[0]).

Francois

Salut,

Le probl�me vient du fait que le caract�re '1' ne vaut pas 1 en valeur binaire (c'est d'ailleurs valable pour tous les chiffres lorsque tu les consid�re comme faisant partie d'une chaine de caract�res)...

De plus, les entiers de type int sont bien souvent cod�s sur un nombre de bit tr�s largement sup�rieur au nombre de bits permettant le codage d'un char...

Il faut donc convertir ton entier en chaine avant de pouvoir faire quoi que ce soit.

Cette entr�e de la FAQ t'indiquera comment faire ;)

Dans le cas qui t'int�resse, cela pourrait prendre la forme de

Code:

---

1 2 3 4 5 6 7 8

std::string pre="variable"; for(int i=0;i<5;++i) { stringstream ss; ss<<pre<<i; std::string final=ss.str(); std::cout<<final<<std::endl; }

---

PS

1. ucstring :question: qu'est-ce donc :question:
2. fromUtf8, c'est pas du java, ca :question:

@ Koala01 : Je ne pense pas que cela r�ponde � la question.

Tu pourrais faire un truc du genre (qui ne r�pond pas non plus completement � la question ;), car il faudrait trouver un moyen de mettre les indices en variables).

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

#include <iostream> #include <string>   #define DECLARE_VARIABLE(indice, valeur) std::string variable##indice = valeur   int main(int argc, char **argv) { DECLARE_VARIABLE(1, "toto"); DECLARE_VARIABLE(2, "titi");   std::cout << variable1 << std::endl; std::cout << variable2 << std::endl; return 0; }

---

Mais de toute fa�on, je n'aime pas trop les macros, et je pense que la r�ponse de Fran�ois est plus adapt�e.
--
J�r�mie

Citation:

---

Envoy� par jfouche

Tu pourrais faire un truc du genre (qui ne r�pond pas non plus completement � la question ;), car il faudrait trouver un moyen de mettre les indices en variables).

---

Bah non, J�r�mie, t'as pas r�fl�chi :aie: : Les macros sont r�solues � la compilations, donc les noms de variable ne peuvent pas �tre d�finis dynamiquement gr�ce � une variable.
--
J�r�mie

En fait, il faudrait voir le type des variables parce que j'avoue que j'ai un peu de mal � cerner le probl�me exact :aie:

Si les variables sont des classes ou des structures, il faut peut �tre se baser sur l'entr�e de la FAQ qui traite de la conversion de n'importe quel objet en string, �ventuellement adapt�e sur base de celle qui traite de la surcharge de l'op�rateur << pour les objets polymoprhes ;)

Et je ne sais toujours pas ce que peut �tre ucstring :D (de prime abord, cela correspondrait � une chaine de caract�res "C style" manipulant l'utf :question:)

Citation:

---

Envoy� par fcharton

Maintenant, tu peux faire un tableau de variables, genre

string variables[5];
ou
vector<string> variables;

que tu acc�deras par leur indice.
variables[0] �tant ce que tu voulais appeler variable1

---

Ou sinon une map<string, void*> semble plus adapt�e si la r�gle de formation des noms n'est pas que num�rique.
Les cl�s seraient alors les noms des "variables" et les valeurs celles des "variables".

Citation:

---

Envoy� par seriousme

Ou sinon une map<string, void*> semble plus adapt�e si la r�gle de formation des noms n'est pas que num�rique.
Les cl�s seraient alors les noms des "variables" et les valeurs celles des "variables".

---

Bof, si on veut passer par une map, autant garder le type d'origine : map<string, ucstring>

En c++, void* est rarement une (bonne) solution. Cela d�note souvent un probl�me de conception.
--
J�r�mie

Merci pour toutes vos r�ponse, finalement je me suis arrang� en utilisant un vecteur.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

vector<ucstring> shardname; ucstring name; name.fromUtf8( row[0] ); // Name prend la valeur de la première ligne d'un requete SQL shardname.push_back( name );   for (int i=0;i<nbrow;i++) { row = mysql_fetch_row(result); // Descend d'un ligne dans le resultat de la requete SQL   name.fromUtf8( row[0] ); shardname.push_back( name ); }

---

Citation:

---

Envoy� par jfouche

Bof, si on veut passer par une map, autant garder le type d'origine : map<string, ucstring>

En c++, void* est rarement une (bonne) solution. Cela d�note souvent un probl�me de conception.
--
J�r�mie

---

Si un seul type de variable est g�r� oui; mais dans le cas g�n�ral, par exemple dans le cadre de la gestion des variables dans un interpr�teur de langages dynamiques, le type void*, ou ses �quivalents (boost::any en C++, object en C#, Object en Java et .Net ...) est tout � fait appropri�, m�me n�cessaire.

Citation:

---

Envoy� par seriousme

Si un seul type de variable est g�r� oui; mais dans le cas g�n�ral, par exemple dans le cadre de la gestion des variables dans un interpr�teur de langages dynamiques, le type void*, ou ses �quivalents (boost::any en C++, object en C#, Object en Java et .Net ...) est tout � fait appropri�, m�me n�cessaire.

---

Je suis tr�s loin d'�tre d'accord avec toi...

Les object (C#) et Object (javai, .NET) ont d�j� une interface qui leur est propre (celle que l'on attend au minimum des objets que l'on manipule)...

M�me boost any est orient� vers le fait que nous parlons de types ayant une s�mantique de valeur ou du moins susceptibles d'�tre convertis l'un en l'autre, alors que void* peut repr�senter strictement tout et n'importe quoi...

Cela signifie que tu en viendrait facilement � faire cohabiter des cuill�res avec des avions � r�action, alors qu'il n'y a, a priori, aucune propri�t� commune...

Et ca, c'est vraiment une tr�s mauvaise id�e et le signe r�el que tu fais sans doute face � un tr�s s�rieux probl�me de conception ;)

Comprend moi bien: Je ne suis pas (tout � fait) oppos� au fait de manipuler des void* en C, car c'est la seule possibilit� qui nous est donn�e de rejoindre d'une certaine mani�re le besoin de polymorphisme...

Mais cela va de paire avec l'obligation de cacher l'impl�mentation et de s'assurer en permanence de passer un pointeur sur le type ad�quat afin d'�viter d'aller chatouiller la m�moire � un endroit mal choisi.

Dans les langages orient�s objet de mani�re g�n�rale (tout comme dans les langages qui proposent le paradigme g�n�rique), il existe une multitude de solutions qui permettent d'�viter ce genre de probl�me, et il me semble des plus important de veiller � les utiliser ;)