Discussion :

[koala01]

on risque de partir dans un débat animé, mais, je crois utile de courir ce risque

D'abord, en ce qui concerne l'optimisation, il faut bien se comprendre: je ne dis absolument pas que toutes les optimisations doivent être "reléguées" au moment où le projet est sur le point d'être livré...

Je dis que toutes les optimisations doivent être faites "en temps utiles", ni avant, ni après, et ne suivant une logique.

Ainsi, il est clair que, si tu dois invoquer trois fois la même fonction pour obtenir la même information, et que cette fonction n'est pas un accesseur "classique" (qui sera bien souvent inliné), il semble opportun de prévoir de garder le résultat de cette fonction quelque part et de le réutiliser (du moins dans la mesure du possible).

Ce que je dis, c'est que, avant de se poser la question de savoir ce qui sera le plus efficace entre l'appel à la fonction ("C Style) sto* ou l'utilisation d'un *stringstream, la chose qui est sure, c'est que si une révision de ton algorithme te permet d'éviter à peu près n'importe quelle proportion de conversion, tu gagnera bien plus de temps à l'exécution, même en utilisant ce qui est "plus lent" qu'en te contentant de choisir la version "plus rapide", simplement parce que la révision de ton algorithme va agir sur un ensemble d'instruction, et non sur une instruction "unique".

Bien sur, certaines optimisations doivent être apportées dés la conception, d'autres au moment de la création de l'algorithme et d'autres enfin au moment du "bench final"...

Le problème est que trop souvent la conception est faite "a posteriori", ce qui enlève toute possibilité de voir " a priori " les problèmes qu'il faudra résoudre et qu'il est encore trop fréquent de voir les gens se "jeter sur leur clavier" et commencer à coder sans avoir la moindre idée de la logique qu'il vont suivre pour atteindre leur objectif, avec comme résultat un code "cochonné" et une perte notable de perfs...

Ensuite, le meilleur moyen pour assurer la qualité d'un code est - AMHA - encore de s'assurer - autant que faire se peut - qu'il soit "revu" par plus d'une personne, ne serait-ce que pour éviter qu'il ne soit "connu" que d'une personne (le coup de la modification "urgente" alors que le type qui a écrit le code est malade/en vacances/parti)

Et il n'empêche que, même si tu es le seul à poser les yeux dessus, il faut prendre en compte que tu risque de le faire après être passé à autre chose parfois pendant plusieurs mois (ce peut "simplement" être le client qui demande une amélioration) , et que ce sera à ce moment là que tu apprécieras (parce que tu aura oublié une partie des décisions non écrites prises lors de la mise au point) d'avoir un code lisible et facilement compréhensible.

Tu me demande si c'est une médiocrité propre à ta boite, je crois pouvoir dire que c'est un problème trop souvent rencontré dans de nombreuses boites: les gens sont des "handicapés de la communication", avec pour résultat que chacun "tire de son coté", sans s'intéresser à ce que font les autres, avec pour résultat qu'il devient difficile de mettre en place une politique de qualité globale...

Je ne serais pas plus étonné que cela que tu me dise que, lors de réunions (s'il en a), on assiste chez toi à d'éternelles discussions du genre de "mais je croyais que c'était toi qui t'en chargeais" ou de "mais je croyais que <tel truc> n'étais pas indispensable"...

Mais bon, ce n'est qu'un avis qui n'engage que moi et sur lequel je n'oblige personne à être d'accord avec moi

En outre, il faut comprendre que les avantages des flux, c'est qu'ils ont une interface commune, et qu'il s'adaptent à tout (et à bien plus qu'aux types primitifs)

A l'extrême limite, si je vois un code proche de

Code :

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

is<<truc<<machin;

je n'ai même pas besoin de me poser la question de savoir de quel flux on parle, je sais que j'y envoie truc et machin

Qu'après je doive réfléchir au fait que c'est un ifstream, un istream ou un istringstream pour pouvoir gérer ce qui a été mis dans le flux est "secondaire" et propre à la fonction que j'étudie

Enfin, tu me demande si ma réponse tenait du "je le savais mais je ne voulais pas le dire".

C'est - à vrai dire - un peu plus complexe que cela.

Effectivement, oui, je savais que cela existe, mais, parce que je ne l'utilise jamais, je l'avais "occulté" (je n'y pensais plus au moment de mes interventions précédentes), et du coup, lorsqu'Azar en a parlé, je me suis effectivement "rappelé" que cela n'avait rien de neuf

Cela tient principalement au fait que, d'une manière ou d'une autre, je n'utilise jamais les fonctions qui mettent en oeuvre des techniques issues du C là où il existe une technique équivalente plus sécurisante à l'emploi propre au C++.

Est-ce un tord à chacun de voir

[Arzar]

Mazette.

Bon alors juste une petite précision, car je ne suis pas sur qu'on parle de la même chose Koala :
Je voulais mentionner l'apparition d'un nouveau panel de fonction dans le draft du C++0x pour résoudre plus facilement le genre de problème évoqué dans ce thread. La première mention dans les papiers du comité date de 2005, dans le papier (bien) nommé Simple Numeric Access. La dernière révision date de 2007, disponible ici. A ma connaissance aucun compilateur ne les implémente sauf GCC dans son mode expérimental C++0x.

Ce sont des fonctions pour l'extraction directe de nombre depuis une std::string. Elles sont parfaitement dans "l'esprit" du C++, par exemple stoi (string to int), prend une std::string par référence constante, renvoi l'int correspondant en cas de succès et lance une exception en cas d'échec.

Plus généralement sur la bibliothèque IOStream :

Je me souviens avoir lu que la biliothèque IOStream complète (locale, filebuf, tout) occupe un tiers de la description des bibliothèques standard du C++, sachant qu'un autre tiers est dévolu... à la STL. Et à ma connaissance le livre de référence, qui permet d'en avoir une vue complète et définitive se nomme: "Standard C++ IOStreams and Locales: Advanced Programmer's Guide and Reference". Selon les critiques sur Amazon, c'est un bouquin extrêmement dense de 672 pages.

Donc, clairement la IOStream est une bibliothèque très puissante, très flexibles, mais aussi très complexe en interne. Et la majorité des programmeurs ne l'utilise qu'en surface, un peu comme un homme préhistorique se servirait d'un tracto-pelle; en tapant dessus jusqu'à ce que ça marche.

Pour les débutants c'est pire. Mon expérience perso : La première fois que j'ai eu besoin d'une fonction d'extraction de nombre, c'était il y a quelques années en TP, pour un truc tout bête, alors que l'on n'avait pas encore vu les flux en cours... Imagine la galère :

• Première tentative, recherche de fonction ToInt, ToString (influence java) -> fail.
• Deuxième tentative, recherche de fonction utilitaire courte comme atoi (influence C) -> fail.
• Finir par se rendre compte qu'il faut utiliser une bête bizarre un "istringstream" (un "ruisseau/torrent/flux/courant/flot de string d'entrée" ? c'est quoi ce truc ?) couplé à des symboles déroutants << et >> (WTF... des ... décalages binaires avec des strings !? ). Ce n'est que bien plus tard que j'ai compris que << et >> étaient des opérateurs, et qu'écrire a << b << c revenait à écrire a.operator<<(b.operator<<(c));

Bon, Ok j'exagère un peu, on finit par prendre le plis, et la gestion de flux devient plus naturelle, mais je ne voit vraiment pas pourquoi il faudrait se lamenter que quelques fonctions supplémentaires abaissent un peu la barrière d'entrée pour les novices, tout en allégeant ponctuellement le sacerdoce quotidien des programmeurs plus expérimentés.

Edit :

C'est ce que je cherchais depuis le début. Je constate que je ne suis pas le seul à se soucier de ce "manque" puisque les gourous du C++ se proposent d'intégrer enfin ce genre de fonction somme toute élémentaire.

HS: Au vu des différents papiers, interviews et conférences sur le C++0x, il me semble que c'est Stroustup qui pousse le plus pour régulariser et uniformiser le langage, ajouter des librairies utilisables directement (XML, filesystem, socket), faciliter la prise en main pour les débutants... ce n'est pas une coïncidence, depuis quelques années maintenant il enseigne le C++.
HS2 : Arf! Et qui retrouve-on derrière le proposal Simple Numeric Access ? Bingo.