Discussion :

[Prosperoh]

En outre, il est préférable d'utiliser cout pour provoquer l'affichage et cin pour la lecture de l'entrée standard (le clavier, le plus souvent).

En effet, printf et scanf sont des fonctions issues du C avantageusement remplacées par cin et cout et leurs opérateurs de flux respectif >> et <<.

Enfin, même en C, la fonction scanf n'est absolument pas recommandée car elle est sujette à de nombreux problèmes

Dans les Cours et tutoriels C++, j'ai lu que dans les exercices du site il fallait mieux utiliser printf et scanf même en C++, à la place de cout et cin, pour des raisons de rapidité :

Les entrées/sorties doivent être implémentées avec la bibliothèque C, et pas la bibliothèque C++ qui est beaucoup plus lente sous Linux (jusqu'à 10 fois !). Utilisez donc exclusivement des scanf et des printf.

Est-ce que cette information est exacte (ou encore d'actualité) ?
En effet, je lis souvent "En C++ on n'utilise plus la bibliothèque standard du C", donc j'ai un doute .

[Invité]

Est-ce que cette information est exacte (ou encore d'actualité) ?

Les entrées sorties formatées C++ sont généralement assez lentes, car elles font pas mal de controles. La lenteur varie d'une implémentation à l'autre (mon expérience est que STLPort est un peu mieux que Dinkumware...), mais elles ne sont pas rapides.

Donc, si tu as un gros fichier à lire, ou à écrire, il faut se méfier des iostream (même il y a des moyens de faire avec, notamment en passant par le mode binaire). C'est typiquement le genre de domaine où les fonctions (non portables) de l'OS gagnent toujours.

Maintenant, pour les affichages sur la console, le conseil donné est un peu ridicule. Sur la console, on affiche généralement de petites quantités de données. La vitesse des fonctions d'entrée sortie n'a alors aucune importance, et la simplicité du code fera préférer les fonctions C++...

Le seul cas où la question pourrait se poser serait celui d'un programme dont la sortie console est destiné à être redirigée vers un fichier (et est de grande taille)...

Francois

[Mac LAK]

Ce qui est le cas typique d'un logger, par exemple...

En dehors de ce genre de cas particulier, c'est à dire des traitements réellement lourds sur des E/S formatées, il vaut mieux utiliser les structures natives du langage, c'est à dire printf/scanf pour le C, et cout/cin pour le C++.

Après, si tu dois effectivement faire un programme manipulant d'énormes quantités de données formatées, la question de l'optimisation est pertinente, mais demande à être étayée via un petit benchmark des diverses fonctions.

[JolyLoic]

Il y a eu un débat au sein du comité C++ à savoir si les E/S du C++ étaient inévitablement plus lentes que celles du C. Ce que j'en ai retenu (il n'y avait pas forcément de conclusion claire), c'est :
- Une partie importante de la lenteur souvent constatés est liée à la gestion de l'internationalisation.
- Il semblerait possible d'avoir une implémentation qui dans le cas d'une locale neutre, où l'on se moque d'internationaliser, ne paierait pas ce coût
- Il n'y a pas de telle implémentation à ce jour (mais si j'ai entendu parler d'une bibliothèque avec une syntaxe semblable mais qui elle ne permettait pas d'I18N du tout, et était plus rapide).

Et de toute façon, là où les performances ont un impact sensible, généralement, on ne fait pas des entrées sorties formatées, et on utilise les fonctions spécifiques du système (par exemple entrées sorties asynchrones sous windows).

[Prosperoh]

Ok merci pour vos réponses, donc à mon niveau d'utilisation du C++ cette lenteur ne me gênera pas beaucoup .

[koala01]

Salut,

Ok merci pour vos réponses, donc à mon niveau d'utilisation du C++ cette lenteur ne me gênera pas beaucoup .

Il y a de fortes chances que ce soit effectivement le cas...

Surtout si tu n'es pas trop à l'aise en C (avec ses E / S du moins) ou si tu dois manipuler des types non POD (std::string en tête)