En faisant des tests avec beaucoup plus d'affichage j'ai remarqué que la première solution (avec le '\n') était bien plus efficace. Malheureusement je ne comprend pas pourquoi ?
Et aussi dans ce cas, pourquoi utilisé std::endl; si l'utilisation de '\n' est plus optimisé.
En pratique, quand on affiche des choses, osef en general des perfs. Et std::endl est plus expressif.
En effet, il n'y a pas besoin de tout optimiser : parfois, on gaspille de l'énergie à optimiser un truc qui gagnerai juste quelques millisecondes... Et on est bien déçu...
Evidemment, dans les boucles critiques, ou les gros calculs, on peut parfois gagner beaucoup. Toute la question est de réussir à anticiper ce qui vaut le coup d'être optimisé, et ce qui ne vaut pas le coup.
En pratique, quand on affiche des choses, osef en general des perfs. Et std::endl est plus expressif.
J'en suis revenu il y a quelques temps déjà.
Et pour les perfs, quand les IO sont un facteur limitant (et j'ai l'impression que c'est vite le cas sur des clusters), et bien on évite d'en faire inutilement. Du coup, quand on produit des gros fichiers texte, inutile en plus de flusher à chaque fin de ligne. (sous-entendu, cela ne sert pas que pour la console -- pire les rares fois où j'ai explicitement besoin de flusher, c'est souvent quand je joue avec `\r`, et là, je ne veux surtout pas aller à la ligne suivante)
Tu dois reconnaitre que quand on arrive à la programmation sur cluster, on en est probablement plus a se poser la question de la différence entre \n et std::endl.
L'idée n'est pas de n'utiliser que std::endl, mais voir l'utilisation de \n comme une optimisation et donc doit suivre la méthodologie habituelle pour optimiser (profiling, profiling, profiling !)
Le truc est que je ne vois pas `\n` comme une optimisation, mais `endl` comme une pessimisation. Exactement pour les mêmes raisons que la préincrémentation est mon défaut, ou que je passe mes chaînes par références constantes, j'utilise `\n` par défaut.
J'aime bien le second exemple, parce que l'on est dans la même lignée: il est plus simple de dire "endl" à un débutant car cela semble avoir un sens fort, plus que "\n" en tout cas. Exactement comme il est plus simple de ne pas leur parler de références constantes. Et pourtant, on a pratiquement tous accepté que "string const&" n'est pas une optimisation, mais la façon idiomatique (pré-C++17).
NB: Ce qui a participé à mon changement de position sur la question, c'est divers débats que j'ai croisés dans la communauté C++ internationale. De la même façon, je suis en train de me poser beaucoup de questions sur signed/unsigned. Mon avis n'est plus aussi tranché qu'avant.
Il faut dire que je fais assez peu d'IHM en console avec les flux standards. Donc mes seules et véritables utilisations de endl, c'est pour produire des fichiers, et là, c'est clairement une pessimisation. Si je veux synchroniser au fur et à mesure, OK, endl. Sinon, '\n', c'est très bien.
PS: pour les cluster, il y a malheureusement beaucoup de questions de base qui passent bien au dessus de la tête de beaucoup d'utilisateurs Genre ça ne semble pas choquer de lire un même (petit) fichier qui ne change pas dans une boucle -- alors qu'il est bien dit partout et tout le temps qu'il y a un problème d'iops très limitant sur le dit cluster cible.
Je reste assez mitigé. Pour le moment, l'argument de la performance me semble trop faible pour justifier l'utilisation de \n par défaut. Je verrais avec le temps si cela change.
Pour unsigned vs signed, c'est en rapport avec la recommandation "int par défaut, size_t pour les tailles/index de conteneurs de la STL" ?
Pour signed/unsigned, c'est tout le débat autour du fait que size_t serait une erreur de conception (*). Que l'on aurait dû rester avec des signés, car au delà des meilleures performances, je vois que vu que les dépassements sont des UB (**), on peut commencer à sortir des outils pour faire des vérifications, à commencer par ubsan, et on peut réver d'un clang-tidy/coverity qui intercepte les dépassements lors d'analyses statiques.
Tant que l'on n'a pas de la ppc officielle avec des outils qui font les vérifs qui vont bien, on ne va jamais pouvoir avoir l'équivalent sur des non-signés si j'ai bien intuité.
(*) OK, sémantiquement, c'est cool un non-signé pour les tailles. Sauf qu'il y a donc des effets de bord pernicieux qui touchent à la fiabilité du code. Ce n'est pas sans me rappeler NULL qui est sémantiquement intéressant, mais un mensonge pernicieux en C++98.
(**) `numeric_limit<size_t>::max() + 1` n'est pas une UB, c'est officiellement 0.
HS : ok. J'avais vu les discussions sur le sujet, mais comme Qt utilise déjà depuis très très longtemps des int pour les conteneurs, c'est une chose que j'ai déjà accepté depuis longtemps (Si Qt et la STL font un choix différent, c'est Qt qui a toujours raison )
EDIT: ça y est, écouté, c'est que 3 minutes 12. Et Le monsieur est celui qui a implémente iostreams. Il avait co-écrit le bouquin de référence sur le sujet avec Angelika Langer. Et on sentait leur style dans la doc de la SL de Roguewave, donnée à la fondation Apache depuis le temps.
Effectivement, il dit "Exprimez ce que vous voulez vraiment faire! Si vous voulez flusher, soyez explicites.". Et sur un test case, endl c'est une dégradation d'un facteur 6 sur un traitement d'un fichier d'un million de lignes de 80 caractères.
× 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.
...
Discord NaN. Mon site.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Discord NaN. Mon site.
Discord NaN. Mon site.
Discord NaN. Mon site.