Sais tu que std::i/o fstream proposent un constructeur acceptant une std::string depuis maintenant près de 7 ans?
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Et; quand bien même (tu as tout à fait raison, ceci dit)... Pourquoi aurais-tu besoin d'une constexpr pour représenter le nom du fichier?
Les expressions constantes représentent une alternative géniale et un moyen inespéré d'optimiser le code binaire résultant. Mais encore faut-il qu'elles aient du sens!
Dés que tu envisages de travailler sur des fichiers, tu risques surtout d'envisager de travailler des fichiers dont le nom ne sera connu... qu'à l'exécution (sans doute parce qu'introduit par l'utilisateur). Et les expressions constantes n'auront dés lors plus vraiment d'intérêt
- Edité par koala01 16 avril 2018 à 0:01:29
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Pas faux, autant utiliser les méthodes les plus modernes, surtout sur ce type de format qui est pour aider le débutant ! :)
Merci pour ton retour ! :+1:
J'essaye d'utiliser un maximum de const, ainsi que de constexpr (quand c'est possible), je fait beaucoup plus confiance aux constantes qu'aux variables ^^
J'essaye d'utiliser un maximum de const, ainsi que de constexpr (quand c'est possible), je fait beaucoup plus confiance aux constantes qu'aux variables ^^
Et tu as bien raison...
Mais, l'un dans l'autre, rien ne t'empêche de récupérer une std::string const depuis une fonction qui utilise une std::string (non const) pour récupérer l'introduction de l'utilisateur
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Nul besoin de garder les lignes si tu veux juste compter. D'autant que cela peut coûter cher si chaque ligne est plus longue que la précédente et qu'il y a bcp de lignes. Bref, pas besoin d'allocation ici.
Le snippet est à changer car ici tu ne cherches pas la n-ième ligne, mais tu veux juste les compter.
Sinon, le nom du fichier est un très bon candidat pour être un paramètre du programme (argv[1]), cela permet d'éviter de recompiler pour tester un nouveau fichier.
On pourrait chipoter quant au choix endl VS "\n". Vu qu'il n'y a qu'une sortie et que c'est à la fin, je n'ai pas d'opinion tranchée.
a) Nul besoin de garder les lignes si tu veux juste compter. D'autant que cela peut coûter cher si chaque ligne est plus longue que la précédente et qu'il y a bcp de lignes. Bref, pas besoin d'allocation ici.
Le snippet est à changer car ici tu ne cherches pas la n-ième ligne, mais tu veux juste les compter.
b) Sinon, le nom du fichier est un très bon candidat pour être un paramètre du programme (argv[1]), cela permet d'éviter de recompiler pour tester un nouveau fichier.
c) On pourrait chipoter quant au choix endl VS "\n". Vu qu'il n'y a qu'une sortie et que c'est à la fin, je n'ai pas d'opinion tranchée.
Merci pour ton retour !
a) Ah bonne idée, je vais sans doute faire 2 exemples du coup, avec l'un pour compter les mots, et l'autre les lignes, ainsi les deux exemples serais utilisé, chacun dans le bon contexte
b) J'hésite, car le but de l'exercice est qu'il soit simple à comprendre pour un débutant (ce pourquoi le code est dans le dossier 'facile'). Je n'ai pas assez travailler avec des débutants en C++ pour savoir si cela peux poser problème. Des idées? (En tout cas c'est un bon sujet 'facile' s'il en était le but)
c) Je part du principe que l'affichage est un processus lent (le cerveau doit le lire), donc grappiller quelques µs dans de l'affichage (je ne parle par d'écriture de fichier ou là, \n remplace std::endl) n'est pas forcément un soucis.
c- Dans les faits, quand on a des traitements qui produisent des millions de lignes, c'est un gain appréciable quand on peut réduire le nombre de flush produits.
Maintenant, ton exemple n'est clairement pas dans cette optique. C'est une question de quelles habitudes faut-il donner? Je ne suis pas sûr d'avoir une réponse à ce stade là.
c- Dans les faits, quand on a des traitements qui produisent des millions de lignes, c'est un gain appréciable quand on peut réduire le nombre de flush produits.
Maintenant, ton exemple n'est clairement pas dans cette optique. C'est une question de quelles habitudes faut-il donner? Je ne suis pas sûr d'avoir une réponse à ce stade là.
Personnellement, j'ai pris l'habitude d'utiliser '\n' au lieu de endl autant que possible, parce que cela permet de ne pas forcer le flush s'il n'est pas nécessaire.
(je crois d'ailleurs que c'est toi qui me l'a inspirée )
Maintenant, je me garderai bien de sortir un argument d'autorité du genre "je fais comme cela, donc vous devez faire comme moi", mais j'ai toujours estimé que si l'on se trouvait face à deux solutions permettant d'obtenir le même résultat mais dont une des deux permettait d'améliorer les performances "à bas prix", il était utile de mettre cette solution en avant.
Par exemple, quand on me demande s'il vaut mieux transmettre un argument par valeur pour par référence constante, ma réponse est: par valeur pour tous les types primitifs (et valeurs énumérées), par référence constante pour tout ce qui est "plus gros qu'un type primitif".
Pourquoi? parce que la copie de structures complexes est un processus qui demande du temps (et, bien souvent, des ressources), et que l'on peut observer des gains de performances non négligeables en transmettant une structure complexe par référence constante sans pour autant créer d'autres problèmes.
Dans le cas présent, nous ne gagnerions que quelque µsecondes à remplacer std::endl par '\n' (en plus de la demi second lors de l'écriture du code gagnée à écrire '\' par rapport au fait d'écrire endl sous son nom pleinement qualifié, si on prend l'habitude de ne pas utiliser la directive using namespace std; qui ne devrait jamais être utilisée ). Mais ce sont les petits ruisseaux qui font les grands fleuves
Est-ce que mon approche qui consiste à privilégier les performances quand c'est possible sans "tout chambouler" est la meilleure approche? Je vais te laisser le soin de juger. Une chose est sure, elle n'est pas la plus mauvaise
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Review d'un bout de code simple
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Architecte logiciel - Software craftsmanship convaincu.
Architecte logiciel - Software craftsmanship convaincu.
Architecte logiciel - Software craftsmanship convaincu.
Architecte logiciel - Software craftsmanship convaincu.