sprintf() versus std::string

Tout d'abord, je ne voudrais pas lancer un troll, ceci dit, je viens de voir dans un thread récent le code suivant:
Code C

Code:

---

1 2	char buffer[512]; sprintf(buffer, "%04X", val);

---

Code C++

Code:

---

1 2 3

std::ostringstream oss; oss << std::setw(4) << std::setfill('0') << std::hex << std::uppercase << val; std::string s = oss.str();

---

Ces 2 code produisent (ou devraient produire) le même résultat

Je sais qu'il y a des puristes du C++ qui ne parleront que de la 2eme approche et que ne voudrons même pas voir la 1ere.

Par contre, en termes de performances, quel est le coup de tout cela ?

Mon avis intuitif est que l'approche C me 'semble' plus performante que l'approche C++ (dans ce cas là). Est-ce que quelqu'un pourrait me convaincre du contraire afin que je fasse le pas pour supprimer/eradiquer cette manière que j'ai d'utiliser le sprintf()

Il me semble aussi que l'approche C est plus compréhensible mais c'est un autre problème, j'ai appris le C il y a 20 ans et le C++ il y a quelques années seulement, il y a des réflexes durs à oublier.

Xio,

Je ne pense pas qu'on puisse dire a priori quelle version sera plus rapide, cela dépendra beaucoup de l'implémentation du compilateur, et des optimisations qu'il saura mettre en place.

Quoi qu'il en soit, je ne pense pas qu'il y ait une énorme différence.

Peu importe la performance à ce niveau là, à moins que tu veuilles appliquer ça à des millions de chaînes. :)

Citation:

---

Envoyé par ram_0000

Par contre, en termes de performances, quel est le coup de tout cela ?

---

C'est vraiment important?

Carl

http://www.ddj.com/cpp/184403882

Citation:

---

Envoyé par 5hdumatin

C'est vraiment important?l

---

Oui cela peut avoir de l'importance si je sais que cela risque d'être effectué plusieurs milliers de fois et que les performances ne sont pas forcément au top (par rapport au sprintf() par exemple), je vais peut être envisager dès le début une autre approche.

En faisant un gros effort pour considérer la question avec des œillères et donc du strict point de vue de la performance:
Dans un cas on a des formattages qui doivent être décodés d'une chaine de format à chaque écriture, dans l'autre le formattage est codé en dur à la compilation par appel de fonction, voire inline. Il est donc fort probable que la version C++ soit plus rapide pour la partie écriture, surtout si le format change peu (la version C++ donne un formattage persistant). En revanche, si le but est de récupérer le résultat dans un tableau, il faut considérer le cout de convertir le contenu des stringstream vers une chaine. Selon l'implémentation, ça peut être un simple retour vers un pointeur qui se fige à l'appel de .str(). Dans ce cas, la version C++ va gagner dans tous les scénarios. Par contre, il y a sûrement des implémentations naïves qui dupliquent le tableau de travail interne à stringstream, et alors si on fait un sprintf bête sans formattage malin directement dans le tableau destination, ça doit aller plus vite.
Pour ce qui est du cout de la duplication finale à l'intérieur d'un objet std::string, il n'est pas comparable, car le résultat des 2 codes est différent: dans un cas on a un tableau de char brut de mémoire, dans l'autre on a un objet puissant std::string.
J'ai du mal cependant à croire que la performance de ce bout de code ait le moindre intérêt dans une vraie application. ;)

Ne pas oublier que les flux C++ permettent de plugguer diverses choses dynamiquement (filtrages, encodages, redirections) dont on n'a pas toujours besoin.

cf à ce sujet les FAStreams, de Maciej Sobczak, qui sont des classes façon flux mais plus optimisées.

Salut,

Citation:

---

Envoyé par ram_0000

Oui cela peut avoir de l'importance si je sais que cela risque d'être effectué plusieurs milliers de fois et que les performances ne sont pas forcément au top (par rapport au sprintf() par exemple), je vais peut être envisager dès le début une autre approche.

---

Ou sinon tu peux aussi attendre de profiler et si ça se révèle le goulet d'étranglement il sera toujours temps de remplacer par des printf.

MAT.

je ne suis pas forcement d'accord. je vois beaucoup de code STL qui fait :

Code:

---

1 2	if(map.find(element) == map.end()) map.insert(std::make_pair(element, value));

---

ce qui cause deux recherches dans l'arbre alors qu'une seule est necessaire. je n'aime pas voir ce genre de code car il n'est pas optimal mais m'apparaitra pas au profiling. or, le mieux est de savoir comment le faire bien du premier coup pour ensuite le faire tout le temps!!

si on sait ce qui est le mieux alors on peut l'employer.

Les printf avec des char tableaux[] je ne suis pas fana pour les employer c'est moins safe que std::string qui est éprouvé.
Ceci si on fait un dépassement de tableau et si c'est mal employé.
D'ailleurs me semble-t-il avec VC++2003 et + on a des security warnings sur printf et compagnie..
Et puis char[] cela tend à être un peu obsolète parce que ça ne supporte pas unicode qui est en 16bits

les memes fonctions existent en w(ide)

Citation:

---

Envoyé par ram_0000

Oui cela peut avoir de l'importance si je sais que cela risque d'être effectué plusieurs milliers de fois et que les performances ne sont pas forcément au top (par rapport au sprintf() par exemple), je vais peut être envisager dès le début une autre approche.

---

Hé hé! Justement! C'était une question piège. Si tu ne peux pas répondre de manière certaine et chiffrée à une question du genre "la performance de ce bout de code est-elle importante?", c'est qu'elle ne l'est pas.

Le profiler de code est ton ami: c'est lui qui a la réponse à ta question.

Carl

Citation:

---

Envoyé par screetch

je ne suis pas forcement d'accord. je vois beaucoup de code STL qui fait :

Code:

---

1 2	if(map.find(element) == map.end()) map.insert(std::make_pair(element, value));

---

ce qui cause deux recherches dans l'arbre alors qu'une seule est necessaire. je n'aime pas voir ce genre de code car il n'est pas optimal mais m'apparaitra pas au profiling. or, le mieux est de savoir comment le faire bien du premier coup pour ensuite le faire tout le temps!!

si on sait ce qui est le mieux alors on peut l'employer.

---

Le but de ce code est d'éviter une modification de l'élément associé à la clef "element" si il est déjà dans la map (car dans ce cas, insert le remplace par le nouvel élément). Les deux recherches sont donc nécessaires et enlever le find() modifie le comportement de l'application.

Citation:

---

Envoyé par Emmanuel Deloget

Le but de ce code est d'éviter une modification de l'élément associé à la clef "element" si il est déjà dans la map (car dans ce cas, insert le remplace par le nouvel élément). Les deux recherches sont donc nécessaires et enlever le find() modifie le comportement de l'application.

---

Non justement, il renvoie une paire dont le second élément indique si l'insertion a eu lieu ou non : http://www.dinkumware.com/manuals/?m...ml#map::insert

comme quoi c'est pas inutile de se poser des questions :)

Citation:

---

Envoyé par 5hdumatin

Si tu ne peux pas répondre de manière certaine et chiffrée à une question du genre "la performance de ce bout de code est-elle importante?", c'est qu'elle ne l'est pas.

---

Si on ne connait pas la réponse à une question, la réponse est négative?

Il y a un problème avec ta logique. :?

Citation:

---

Envoyé par Mat.M

unicode qui est en 16bits

---

Unicode n'est pas "en 16 bits" : il y a plus de 2**16 code-point Unicode.

Citation:

---

Envoyé par Emmanuel Deloget

(car dans ce cas, insert le remplace par le nouvel élément).

---

Non, insert ne remplace pas un élément (pour n'importe quel conteneur associatif).

Citation:

---

Envoyé par corrector

Non, insert ne remplace pas un élément (pour n'importe quel conteneur associatif).

---

Toutes mes confuses alors. Pour une fois que je vérifie pas avant de poster... :oops: