Problème de std::cout

hello les amis,

un gros pepin se trouve face a moi :mrgreen:

quand je fais cela :

Code:

---

cout << "Frequency" << getFreq() << endl;

---

je recupere par exemple Haute

or quand je recupere dans un fichier ini :

Code:

---

settings.setValue("FreqInMHz",getFreq() );

---

je recupere 1

Il faut noter que getfreq() recupere depuis un enum du type :

Code:

---

enum FrequencyEnum {Basse=0, Haute, Moyenne, INVALID};

---

comment faire pour recuperer directement ces string.
quel est lq difference entre cout et le fait de prendre directement getfreq()

thanks:mouarf::ccool:

En Qt on utilise plutôt qDebug que cout, mais je pense que ça devrait marcher pareil. Essaye quand même au cas où...

Pour récupérer le nom, je crois qu'il n'y a pas le choix, tu fais une fonction intermédiaire qui renvoie un String suivant la valeur (tu mets chaque valeur/string en dur dans un switch case par exemple).

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

const QString& Classe::getFreqStr() { int freq = getFreq(); QString str;   switch (freq) { case Basse: str = "Basse"; break; case Haute: str = "Haute"; break; case Moyenne: str = "Moyenne"; break; default: str = "INVALID"; }   return str; }

---

Il doit probablement avoir un operator<< défini ( avec un "enum FrequencyEnum" en paramètre ) qui doit probablement faire le switch proposé par Troudhyl. Une solution serait d'utiliser cet operateur pour remplir ta chaine !

Ou peut-être une histoire de cast (le setValue caste peut-être en int en premier ), mais regarde l'operator<< avant !

Merci a vous deux.

J'ai utilisé la methode deTroudhyl =======> fonctionnel

Je vais regarder de plus pres la tienne bobti89:ccool:

merci

Tiens-nous au courant stp, la méthode de bobti89 m'intéresse aussi ^^

Plus simple ?

Code:

---

1 2 3 4

enum FrequencyEnum { Basse=0, Haute, Moyenne, INVALID }; const char* FrequencyEnumStr[] = { "Basse", "Haute", "Moyenne", "INVALID" }; ... cout << "Frequency" << FrequencyEnumStr[(int) getFreq()] << endl;

---

Citation:

---

En Qt on utilise plutôt qDebug que cout, mais je pense que ça devrait marcher pareil. Essaye quand même au cas où...

---

La grosse différence entre cout et qDebug est que le second prend en charge les types natifs de Qt (QString, QVector, etc.)

Oui voilà mais dans ce cas précis c'est la même chose, la sortie est la même... Quand je fais du Qt j'écris le moins possible de C++ (cout / endl... illisible).

Effectivement ton code est bien plus court. Mais j'ai édité le mien pour montrer l'intention que je voulais : un code qui marche et soit lisible quelles que soient les valeurs entières des énumérations.

Citation:

---

Envoyé par Troudhyl

Quand je fais du Qt j'écris le moins possible de C++ (cout / endl... illisible).

---

Hum, quand tu fais du Qt, tu fais du C++. Je rappelle que Qt n'est qu'un framework, pas un langage. Donc ça me dérange pas de faire du C++ dans du C++ :)

Citation:

---

Envoyé par Troudhyl

Effectivement ton code est bien plus court. Mais j'ai édité le mien pour montrer l'intention que je voulais : un code qui marche et soit lisible quelles que soient les valeurs entières des énumérations.

---

Un code d'une ligne ou une code de 20 lignes n'ont pas la même lisibilité. De plus, imagine que tu aies 20 options dans ton énumération : tu nous fais un switch de 200 lignes ? C'est pas génial.

Ensuite, chacun est libre de faire le code qu'il préfère, mais je revendique un droit à la paresse dans ce cas : plus c'est court et rapide à taper, mieux c'est.

Citation:

---

Envoyé par gbdivers

Hum, quand tu fais du Qt, tu fais du C++. Je rappelle que Qt n'est qu'un framework, pas un langage. Donc ça me dérange pas de faire du C++ dans du C++ :)

---

Tout à fait, c'est probablement parce que tu connaissais le C++. Moi j'ai fait Java => Qt => C++ (miam les fuites mémoires au début :D), et je trouve un code en C++ pur vraiment indigeste, illisible, comparé à du Java/Qt qui peut se lire comme un bon bouquin :p Le CamelCase joue sûrement beaucoup.

Citation:

---

Envoyé par gbdivers

Un code d'une ligne ou une code de 20 lignes n'ont pas la même lisibilité. De plus, imagine que tu aies 20 options dans ton énumération : tu nous fais un switch de 200 lignes ? C'est pas génial.

Ensuite, chacun est libre de faire le code qu'il préfère, mais je revendique un droit à la paresse dans ce cas : plus c'est court et rapide à taper, mieux c'est.

---

Ça se discute, est-il plus facile de maintenir un switch case qui met en évidence l'association énumération => string, ou gérer un long tableau de char* déclaré en dur à mettre en parallèle avec l'énumération... Bon ok on va dire que c'est faisable en faisant attention.

Pour ma part je pense qu'un enum est fait pour être utilisé en tant que symbole (d'ailleurs ce concept (différence entre symbole et chaîne) en ruby est vraiment intelligent). Afficher ces valeurs sous forme de chaînes pourquoi pas quand on debogue, mais sinon autant choisir une autre structure de donnée, comme des static const QString, ou un QSet/QHash de QString.

Dans ton cas, je ne vois pas en quoi c'est dérangeant que ton fichier ini stocke une valeur entière, personne n'ira le lire non ? et ton programme fera directement le lien entre l'enum et la valeur du fichier. Passer par des chaînes pour écrire, puis retransformer les chaînes en enum à la lecture, je trouve ça inutile.