Discussion :

[camboui]

Je n'ai jamais utilisé std::string. Je commence donc, il n'est jamais trop tard
Mais me voici sur un premier soucis, convertir des "valeurs" en string. Bref, je cherche de quoi faire l'équivalent des itoa, sprintf, etc, avec des string.
Merci.

[Invité(e)]

Bonjour,

La FAQ ?

[camboui]

Oui, merci.
A défaut de mieux je passe parfois par l'intermédiaire des strstream, mais je trouve ça particulièrement lourd et peu élégant. J'en arrive à préfèrer alors ce bon vieux et efficace itoa(), la conversion de 'int' ou 'unsigned' en str étant un cas (très) fréquent. Dans d'autres cas le sprintf() est assez génial pour tout type de présentation des nombres (precision, mantisse, base, etc).

Il n'y a pas d'équivalent en manipulant directement les std::string ? Une classe dérivée avec des méthodes supplémentaires ?

[Spout]

Il n'y a pas d'équivalent en manipulant directement les std::string ? Une classe dérivée avec des méthodes supplémentaires ?

Non.

La classe template std::string sert à manipuler..... des string. Pour faire une conversion vers ou depuis des nombres, tu es obligé de passer par les flux (pour la STL en tout cas).

[Nogane]

Il n'y a pas d'équivalent en manipulant directement les std::string ?

Non mais rien ne t'empêche de te faire des petites fonctions template qui te convertisse n'importe quoi en string, et un string en n'importe quoi. En utilisant les stringstream.

Un exemple se trouve ici:
http://farscape.developpez.com/Articles/Conversions/

[JolyLoic]

Il y a boost::lexical_cast qui emballe cette méthode dans un appel de fonction unique.

[camboui]

Merci, je vais regarder un peu tout ça. Et apronfondir les strstream.

Au fait, c'est quoi c++/cli ? Jamais entendu parler...

[koala01]

Salut,

Honnetement, je ne vois pas vraiment ce qu'il y a de "si lourd que cela" à écrire un code proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
const std::string convert()
{
float f = 3.1415926;
int i = 5;
std::stringstream ss;
ss<<"le reel vaut :"<<f<<" et l'entier :"<<i;
return ss.str();
}

quand on voit les soucis qui peuvent apparaitre avec les fonctions issues du C...

En plus, l'utilisation de flux de base (istream et ostream) te permet de t'assurer une certaine continuité dans le traitement des classes:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
class MaClass
{
    public:
        MaClass():f(301415926),i(5){}
        friend class std::ostream& operator<<(std::ostream& ofs, const MaClass& c)
        {
            ofs<<"le reel vaut :"<<f<<" et l'entier :"<<i;
            return ofs;
        }
};

pourrait être, à ton gout, utilisé des manières suivantes:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
int main()
{
    /* création d'une instance de la classe */
    MaClass c;
    /* affichage sur la sortie standard */
    std::cout<<c<<std::end; /* nous aurions pu choisir cerr ou clog, si nous
                            * avions voulu un rapport d'erreur ou un log
                            * d'activités ;-) 
                            */
    /* ou l'écrire dans un fichier particulier */
    std::ofstream ofs("fichier.txt");
    ofs<<c<<std::endl;
    /* et même en arriver à convertir le tout en std::string */
    std::stringstream sstr;
    sstr<<c;
    std::string s = sstr.str();
    return 0;
}

Comme tu l'aura remarqué, l'énorme avantage à l'utilisation des flux de données est *réelement* de fournir une syntaxe identique en tous temps

[camboui]

OK, convaincu, merci
Ce n'est qu'une (bonne) habitude à prendre finalement.

[koala01]

OK, convaincu, merci
Ce n'est qu'une (bonne) habitude à prendre finalement.

Exactement...

En allant à peine plus loin, et bien que je connaisse le C et que je lui accorde tout le crédit qu'il mérite, je dirais même que la bonne habitude à prendre est de toujours préférer les solutions propres au C++ lorsqu'elles existent à toute alternative issue du C...

A de très rares exceptions près (car il est vrai qu'il n'est pas vraiment évident d'implémenter un algorithme md5 avec les std::string) ce sera de nature à t'apporter facilité et sécurité

[camboui]

Je remonte un peu ce fil car, bien que "facile" et "lisible", l'usage de string et stringstream ne semble pas très performant.
Je me demandais donc si ce code peut rendre la conversion plus rapide:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
std::string s;
s.resize(12);
itoa(value,s.begin(),10);

Mais je vous vois déjà hurler d'ici...
Ou alors quelque chose comme ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
std::string s;
s.resize(12);
itoa(value,reinterpret_cast<char *>(s.data()),10);

Je sais ce n'est pas propre.
Mais le but est de demander à std::string d'allouer un certain espace contigu et de le proposer à l'extérieur pour utilisation en écriture (dans l'optique d'éviter des copies multiples).

En marge, je constate que d'une manière générale, l'usage des stream et de string génère du code qui passe plus de temps à allouer et copier des tampon de mémoire qu'au traitement fonctionnel désiré.

[camboui]

Je retire temporairement le caractère résolu de ce fil pour avoir votre avis.

Si j'ai bien compris, le moyen "propre" pour accéder au contenu d'un std::string en écriture est de passer par un iterator. Du coup je ne vois pas d'autre moyen que de réécrire l'algo de conversion, comme ceci par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
std::string ul2string(unsigned long value)
{
char buf[12];
char *bufp=buf;
for(;;)
{
	*bufp++=(char)(value % 10u);
	if ((value/=10u)==0ul)
		break;
}
std::string s;
s.resize(bufp-buf);
std::string::iterator it_s=s.begin();
while (bufp!=buf)
{
	char c=*--bufp;
	*it_s=(char)(c+'0');
	++it_s;
}
return s;
}

Ce code me semble sûr et portable car indépendant de l'implémentation de std::string.
Une alternative est de passer la std::string en paramètre par référence plutôt que de la renvoyer par valeur.

[3DArchi]

Ce n'est pas une bonne idée. Ne serait-ce que parce que rien ne te garantie la taille d'un unsigned long! Sur 64 bits, ton char[12]
La bonne solution reste de passer par les stream.

[camboui]

J'avais pensé à ce
char buf[12];
qu'on peut judicieusement remplacer par
char buf[LONG_MAX_DIGITS];
... à condition qu'il existe une macro défine par le compilateur (oui mais en base 10 , 2, 16 ?).
Sinon voici
char buf[sizeof(long)*3];

[3DArchi]

char buf[sizeof(long)*3];

Intuition ou t'arrives à démontrer qu'un hexadécimal à 2n digits est borné par 6n digits en décimal? Je pense que tu cherche une mauvaise solution à un faux problème...

[camboui]

...
un hexadécimal à 2n digits est borné par 6n digits en décimal?
...

Oui.

[koala01]

Je remonte un peu ce fil car, bien que "facile" et "lisible", l'usage de string et stringstream ne semble pas très performant.
Je me demandais donc si ce code peut rendre la conversion plus rapide:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
std::string s;
s.resize(12);
itoa(value,s.begin(),10);

Mais je vous vois déjà hurler d'ici...
Ou alors quelque chose comme ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
std::string s;
s.resize(12);
itoa(value,reinterpret_cast<char *>(s.data()),10);

Je sais ce n'est pas propre.
Mais le but est de demander à std::string d'allouer un certain espace contigu et de le proposer à l'extérieur pour utilisation en écriture (dans l'optique d'éviter des copies multiples).

En marge, je constate que d'une manière générale, l'usage des stream et de string génère du code qui passe plus de temps à allouer et copier des tampon de mémoire qu'au traitement fonctionnel désiré.

A vrai dire, ce qui me fait hurler, c'est que tu oublie un principe essentiel:

un code source est plus souvent étudié ou lu que compilé

La première qualité d'un code (j'irais presque jusqu'à dire: avant même que celle qui consiste à faire ce qu'on attend de lui) est donc... d'être facilement lisible par la personne qui l'a devant les yeux

De plus, je ne le répéterai jamais assez, la solution la plus simple est toujours la moins compliquée... heu... pardon: la meilleure

Partant de là, il me semble bien plus cohérent d'avoir recours à... des solutions "simples", et tu avouera que celle qui passe par les flux de conversions est clairement celle qui donne un résultat cohérent en demandant la logique la moins complexe

Enfin, il ne faut pas oublier que, tant la classe string que les classes *stringstream sont à la base des classes template (même si elles le cachent bien)...

Cela implique que le compilateur a toutes les latitudes possibles pour apporter des optimisations et fournir quelque chose qui sera - au final - vraisemblablement bien plus optimisé que tout ce que tu pourrais faire de ton coté

Je retire temporairement le caractère résolu de ce fil pour avoir votre avis.

Si j'ai bien compris, le moyen "propre" pour accéder au contenu d'un std::string en écriture est de passer par un iterator. Du coup je ne vois pas d'autre moyen que de réécrire l'algo de conversion, comme ceci par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
std::string ul2string(unsigned long value)
{
char buf[12];
char *bufp=buf;
for(;;)
{
	*bufp++=(char)(value % 10u);
	if ((value/=10u)==0ul)
		break;
}
std::string s;
s.resize(bufp-buf);
std::string::iterator it_s=s.begin();
while (bufp!=buf)
{
	char c=*--bufp;
	*it_s=(char)(c+'0');
	++it_s;
}
return s;
}

Ce code me semble sûr et portable car indépendant de l'implémentation de std::string.
Une alternative est de passer la std::string en paramètre par référence plutôt que de la renvoyer par valeur.

Personnellement, il y a trois points qui me chagrinent énormément:

• j'ai horreur de ne pas donner les trois paramètres nécessaires à une boucle "pour"
• L'utilisation de l'instruction break m'horripile s'il y a moyen de faire autrement
• Quitte à ce que cela prenne quelques lignes de code de plus, je préfère respecter la règle du "une ligne, une instruction", et éviter au maximum les effets de bord...

Ce n'est sans doute que pinaillage et "capilotraction", mais j'aurais fortement préféré quelque chose qui prenne une forme proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
while(value>0)
{
    *bufp=(char)(value%10);
    value/=10;
    bufp++;
}

[camboui]

Et voilà comment on change un code correct en un code incorrect, en prétendant le code initial illisible. Permet-moi ainsi de corriger ta correction

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
do
{
    *bufp=(char)(value%10);
    value/=10;
    bufp++;
}
while(value>0);

Dans le cadre du forum, j'apprécie ton intervention pour corriger le code "illisible", car elle peut m'aider à me débarraser de certaines (mauvaises ?) habitudes. Mais en entreprise, changer le code ancien mais éprouvé d'un vieux singe sous prétexte de lisibilité est passible au mieux d'une prime ou d'une augmentation manquée, au pire de... Surtout quand le code modifié ne répond plus aux attentes.

Cependant, je n'ai pas la réponse à mon interrogation.
Suis-je en droit de mettre en doute le caractère répétitif et non nécessaire des multiples allocations et copies de tampons de mémoire lorsqu'on passe par l'intermédiaire des stringstream ?
Ou bien est-ce que j'écrase et je fais comme il se doit d'être fait sans chercher à faire mieux ? (en appliquant à la lettre le dicton qui dit que "le mieux est l'ennemi du bien").

[koala01]

Et voilà comment on change un code correct en un code incorrect, en prétendant le code initial illisible. Permet-moi ainsi de corriger ta correction

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
do
{
    *bufp=(char)(value%10);
    value/=10;
    bufp++;
}
while(value>0);

Effectivement, j'étais un peu fatigué lorsque j'ai écrit le code

Dans le cadre du forum, j'apprécie ton intervention pour corriger le code "illisible", car elle peut m'aider à me débarraser de certaines (mauvaises ?) habitudes. Mais en entreprise, changer le code ancien mais éprouvé d'un vieux singe sous prétexte de lisibilité est passible au mieux d'une prime ou d'une augmentation manquée, au pire de... Surtout quand le code modifié ne répond plus aux attentes.

Je te l'accorde, mais, le fait de jouer avec les effet de bords et de faire plusieurs choses à la fois n'est de toutes manières jamais bon

Et tu as semble-t-il trouvé rapidement le défaut de ma logique

Cependant, je n'ai pas la réponse à mon interrogation.
Suis-je en droit de mettre en doute le caractère répétitif et non nécessaire des multiples allocations et copies de tampons de mémoire lorsqu'on passe par l'intermédiaire des stringstream ?
Ou bien est-ce que j'écrase et je fais comme il se doit d'être fait sans chercher à faire mieux ? (sans oublier que parfois le mieux est l'ennemi du bien).

Sauf erreur, les buffers alloués le sont de manière "compensée".... Ce n'est pas parce que tu aurais 20 éléments à placer dans ton buffer que tu auras... 20 allocations et autant de libération de mémoire

En outre, je te rappellerais trois principes importants:

• Dans, mettons, 90% des cas, une optimisation prématurée est la route de toutes les enfers

• L'exécution passe généralement 80% de son temps dans 20% du code

• Avant de vouloir gagner quelques cycles d'horloge en cherchant la "meilleur manière d'écrire quelque chose", il est bien plus intéressant de trouver la logique qui permettra d'éviter le maximum d'itération "non nécessaires"

Bref, selon moi, dans un premier temps, il vaut mieux écraser et faire "comme il se doit" (bien que, dans ce cas, j'aurais tendance à plutôt dire "au plus facile" )

Si, vraiment, lors du profiling, tu te rend compte que la méthode "simple" demande énormément de temps et / ou de ressources, ta première réaction devrait être de s'interroger sur la complexité des algorithme et de voir s'il n'est pas possible de la diminuer (passer d'une complexité en O(n) à une complexité en O(log(n)), par exemple ou, simplement, t'assurer de l'utilité des chaque conversion )

Si l'objectif n'est toujours pas atteint une fois que tu as la certitude que tes algorithme ne font pas plus de conversions que nécessaire et que le profiling t'indique clairement que ce sont les conversions qui sont encore le "goulot d'étranglement", alors, il sera toujours temps de réfléchir à un moyen plus rapide d'effectuer les conversions, et de ne le garder que si le gain est réellement significatif (re-profiling et benchmarks à l'appui )

[koala01]

J'aurais pu (du ) éditer ma réponse pour y rajouter ce qui suit, mais comme je te propose une autre manière d'envisager les choses, autant te faire une autre réponse

En effet, l'une des solutions envisageables pour éviter au maximum les conversions pourrait être de travailler avec un cache.

Tu déclares une variable de type "chaine de caractères" qui "suit" ta valeur numérique, que tu vide lorsque la valeur numérique change dont tu teste le contenu (vide ou non) avant d'effectuer la conversion.

De cette manière la conversion peut n'être effectuée qu'une fois au lieu de (bien souvent) entre deux modifications de la valeur