perdu dans les pointeurs

Citation:

---

Envoyé par atttchoum

Voila qui m'étonne j'ai toujours trouvé que la classe string était franchement radine en fonctions utiles comparé à d'autre librairie (genre QString).

---

Il est vrai qu'elle ne fournit pas de possibilité de conversion std::string <--> type primitifs / entiers / réels (ca, c'est du domaine des *stringstream), mais peut être n'a tu pas un aperçu complet de son interface publique à laquelle il ne faut pas oublier de rajouter les fonctions / membres statiques :aie:

On pourrait toujours regretter l'absence d'une fonctionnalité propre à nos besoins ou d'une autre, mais certains (et je ne dis pas que c'est mon cas, hein :D) estiment déjà qu'elle fait un peu trop "couteau suisse" :P

Citation:

---

Envoyé par atttchoum

justement l'une des fonctionnalités qui manque vraiment à la classe string. Il faut utiliser un textstream si je me souvient bien.

---

il faut en fait utiliser stringstream, mais c'est quelque part normal...

Il n'y a aucune raison de donner la responsabilité d'une conversion chaine de caractères<--> autre chose à... la chaine de caractères.

Sa responsabilité qui consiste à... gérer correctement les chaines de caractères est déjà suffisamment importante pour que nous ne lui en demandions pas plus :D

Citation:

---

Envoyé par Pierre Dolez

Bonjour Atttchoum,
Je vais vous confier un secret. Il y a 10 ans à peu près, quand j'ai acheté mon nouveau compilateur, j'ai regardé les possibilités de la classe string par rapport à ce dont je disposais. En particulier les facilités d'impression et le remplacement éventuel de ma fonction ftoa(). J'ai rien trouvé de particulièrement folichon. Alors, j'ai pris les possibilités qu'offrait le C++, et j'ai laissé les containers où ils étaient. En d'autres termes, j'ai continué à faire du développement, pour la programmation, ma machine et moi, on se comprend.

---

Le fait est qu'il y a dix ans, C++ venait à peine d'être normalisé.

De plus, comme tu parles d'achat d'un compilateur, je pense tout de suite (peut être à tord) que le compilateur que tu as acheté venait de... chez microsoft ou de chez borland qui n'étaient pas vraiment connu à l'époque pour leur respect des normes.



Depuis, il y a eu:

1. une autre norme finalisée (en 2003)
2. un Technical Report (en 2005)
3. un changement de philosophie chez microsoft comme chez borland(depuis, ils font beaucoup plus attention aux différentes normes)
4. certains projets fournissant ce que la norme a oublié (boost en tête)
5. une nouvelle norme en cours de finalisation

Il faut donc se dire que ce qui était vrai à l'époque ne l'est vraiment plus à l'heure actuelle, et je dirais presque qu'il est du devoir du développeur de réfléchir un minimum à l'opportunité de se "mettre à jour" :D

Citation:

---

Envoyé par Pierre Dolez

A propos des "fonction utiles de la classe string", comment fabriquer une chaine qui représente la valeur d'un nombre décimal à afficher?

---

Code:

---

1 2 3

ostringstream oss; oss << monNombre; // On peut ajouter des options de format, de précision... string maString = oss.str();

---

Si on ne veut pas d'options de formatage, il y a le raccourci :

Code:

---

string maString = lexical_cast<string>(monNombre);

---

L'avantage étant que ça marche quelque soit le type de monNombre, pour peut qu'on ait prévu un opérateur << associé, ce qui est donc bien plus flexible que les xtoy ou autres options du genre.

Bonjour Koala,

Citation:

---

Il faut donc se dire que ce qui était vrai à l'époque ne l'est vraiment plus à l'heure actuelle, et je dirais presque qu'il est du devoir du développeur de réfléchir un minimum à l'opportunité de se "mettre à jour"

---

Ok, je suis d'accord que c'est le devoir du programmeur, celui du développeur est de développer.
JolyLoic est intervenu entre temps, bonjour.
Je ne cherche en aucun cas à dire que j'ai raison, je dis seulement comment je fais, pourquoi je fais comme ça, et que pour l'instant, ça m'a réussi pas trop mal.
Autre façon de considérer les choses, j'ai besoin d'un traducteur, on appelle ça langage en informatique, pour expliquer à ma machine ce que je veux qu'elle fasse, et ca ne va pas plus loin.
J'ai beaucoup développé avec un langage interprété (Jiscad). Bien que la syntaxe soit très différente, la logique du développement reste la même, quelque soit le langage. C'est la seule chose qui me parait importante, et ce que j'essaye de dire se limite à cela.

mais bon, c'est pas très logique d'abandonner les containers ( vector, list, string ) parce qu'il n'y a pas directement en C++ une fonction StrToFloat.

Citation:

---

Envoyé par Pierre Dolez

Je ne cherche en aucun cas à dire que j'ai raison, je dis seulement comment je fais, pourquoi je fais comme ça, et que pour l'instant, ça m'a réussi pas trop mal.
Autre façon de considérer les choses, j'ai besoin d'un traducteur, on appelle ça langage en informatique, pour expliquer à ma machine ce que je veux qu'elle fasse, et ca ne va pas plus loin.
J'ai beaucoup développé avec un langage interprété (Jiscad). Bien que la syntaxe soit très différente, la logique du développement reste la même, quelque soit le langage. C'est la seule chose qui me parait importante, et ce que j'essaye de dire se limite à cela.

---

Lorsque tu crées ton algorithme, surtout si tu veux le faire sans imposer de langage particulier, il est effectivement de bon ton de ne pas s'inquiéter de la manière dont ce sera réellement traduit en code.

Par contre, lorsque tu traduis ton algorithme en code, il est à tout le moins dommage de se "faire du mal pour rien" à coder "à l'ancienne" (comprend: sans profiter de toutes les possibilités du langage) quand on sait que le langage offre des possibilités plus sécurisantes à l'emploi.

Dans certains cas (comme, pour n'en citer qu'un, la gestion dynamique de la mémoire), il n'y aura d'ailleurs qu'un pas entre "dommage" et "potentiellement dangereux" ;)

Citation:

---

Envoyé par koala01

On pourrait toujours regretter l'absence d'une fonctionnalité propre à nos besoins ou d'une autre, mais certains (et je ne dis pas que c'est mon cas, hein :D) estiment déjà qu'elle fait un peu trop "couteau suisse" :P

---

string est un affreux monolithe:

http://www.gotw.ca/gotw/084.htm

Citation:

---

Envoyé par Joel F

string est un affreux monolithe:

http://www.gotw.ca/gotw/084.htm

---

C'est effectivement l'avis de certains... Libre à tout autre de le partager ou non.

Pour ma part, je ne m'exprime simplement pas (en fait, je garde mon avis pour moi):D

Citation:

---

Envoyé par JolyLoic

Code:

---

string maString = lexical_cast<string>(monNombre);

---

L'avantage étant que ça marche quelque soit le type de monNombre, pour peut qu'on ait prévu un opérateur << associé, ce qui est donc bien plus flexible que les xtoy ou autres options du genre.

---

C'est malheureusement uniquement boost ça (ou peut-être Tr1). :(. Ce serait trop facile sinon :aie:.

Joel F-> je suis d'accord, mais par-ce que trops de méthodes sont implémenté pour le string. En suite, je ne vois pas trop l'inconvénient de méthodes inlinées qui appelerait un algorithme général... a part pour les mauvaises habitudes, mais je pense que l'objectif de la classe string était de rassurer les "débutants" dans le langage et pour avoir un syntaxe type "full objetct".

Par -ce que la syntaxe type

Code:

---

std::find(MonString.begin(),MonString.end(),'a');

---

y'a pas mal de débutants qui lâcheraient direct... :s.

C'est vrai que d'un point de vue conception, c' est pas l'optimal et ça peut donner de mauvaises habitudes au gens, mais ça ne retire rien à la performance du langage... et du moment que c'est une surcouche d'algorithmes génériques, ça permet de pouvoir utiliser ces algorithmes de façon plus générique :)

Citation:

---

Envoyé par méphistopheles

C'est malheureusement uniquement boost ça (ou peut-être Tr1).

---

boost, tr1 et c++0x.

Faut surveiller va y'avoir une nouvelle implémentation de lexical_cast avec du spirit derrière... ça va être assez énorme. (plus rapide q'itoa par exemple)

Citation:

---

Envoyé par Goten

Faut surveiller va y'avoir une nouvelle implémentation de lexical_cast avec du spirit derrière... ça va être assez énorme.

---

Spirit 8O Je sens que les temps de compilation aussi vont être énormes :aie:

Non, c'est loin d'être horrible. (juste ce qu'il faut d'inclusion etc, et la V2 de spirit qui a très très largement améliorer les temps de compilation)

Citation:

---

Envoyé par JolyLoic

Code:

---

string maString = lexical_cast<string>(monNombre);

---

---

D'ailleurs, sur les compilateurs récents, comme vs2010 ou gcc 4.4, on peut aussi faire :

Code:

---

1 2 3 4

#include <string> int i = 2; std::string s = std::to_string(i); int j = std::stoi(s);

---