Discussion :

[ram-0000]

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 :

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

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

Code C++

Code :

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

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.

[droggo]

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.

[Invité]

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

C'est vraiment important?

Carl

[Luc Hermitte]

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

[ram-0000]

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.

[ac_wingless]

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.

[Luc Hermitte]

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.

[Mat007]

Salut,

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.

[screetch]

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

Code :

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

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.

[Mat.M]

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

[Emmanuel Deloget]

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

Code :

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

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.

[Invité]

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

[corrector]

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.