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)

[LoDev]

Salut à tous,

après avoir lu l'ensemble de la discussion, il me reste un point en suspend. A priori, cout serait un peu plus lent suivant son utilisation.

Ma question se pose pour vider la sortie standard.
En C pour débugger de lourdes applications, il m'arrive d'utiliser des printf (en C) ou cout (en C++), c pas très beau, mais quand on n'a pas le choix...

Le "cout" vide t il automatiquement la sortie standard, comme c'est un stream?
Ou est il moins performant qu'un printf, fflush(stdout); ?

Merci

[Médinoc]

L'objet cout "flushe" sa sortie quand il reçoit un manipulateur endl;

[Arzar]

Salut,

Le "cout" vide t il automatiquement la sortie standard, comme c'est un stream?

Si je me souviens bien on a :

Code :

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

1
2
3
4
5
6
 
std::cout << "Hello \n"; // ne flush pas
std::cout << "Hello" << endl; // flush
 
std::cout << "Hello \n"; // affiche...
std::cout << flush; // et flush

Donc en règle générale cout ne flush pas la sortie. Il faut toutefois faire attention à std::endl. Il rajoute un "\n" dans la chaine et flush la sortie.

[screetch]

l'argument principal de cout sur printf c'est que cout est fortement typé.
l'inconvénient principal (dépend de la personne bien sûr) c'est que la syntaxe pue. Elle pue 100% en tous cas dans un cas, celui ou la chaîne de caractere doit etre traduite.

l'idéal serait plutot une sorte de printf fortement typé, qui combine les avantages de la syntaxe claire de printf et la stabilité de cout.

[ptyxs]

Pas compris grand chose à ton message un peu rapide, tu pourrais développer ?
Qu'est-ce qui pue au juste ? Et qu'est-ce que cette différence de "typage fort" ?

[screetch]

par "cout fortement typé" j'entends que printf ne valide pas son entrée (il y a un warning pour GCC mais c'est tout)
du coup, si tu fais

Code :

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

printf("%s\n", std::string("Hello, world!"));

ca va compiler très bien, puis ca va planter violemment a l'éxécution car %s attend un pointeur sur une chaine, et on lui file une std::string. De même, si tu te trompes dans le format, inverse le float et l'entier, etc etc...

pour cout, le problème c'est la syntaxe; principalement parce que la phrase est coupée en morceaux. Si elle doit etre traduite, ca va rendre la traduction compliquée, voire impossible.

Code :

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

cout << "You have found " << 2 << "gold";

maintenant il va falloir traduire séparément les deux bouts de phrase, sans savoir qu'ils étaient en fait liés
l'avantage de printf ici c'est que la phrase reste en un seul morceau, il eest possible de la reformatter au besoin

[JolyLoic]

par "cout fortement typé" j'entends que printf ne valide pas son entrée (il y a un warning pour GCC mais c'est tout)
du coup, si tu fais

Code :

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

printf("%s\n", std::string("Hello, world!"));

ca va compiler très bien, puis ca va planter violemment a l'éxécution car %s attend un pointeur sur une chaine, et on lui file une std::string. De même, si tu te trompes dans le format, inverse le float et l'entier, etc etc...

Outre l'aspect erreur lors de la première écriture du code, ce problème devient encore plus sensible lors de l'évolution si tu décides de changer le type d'une variable, tu dois repasser partout.

pour cout, le problème c'est la syntaxe; principalement parce que la phrase est coupée en morceaux. Si elle doit etre traduite, ca va rendre la traduction compliquée, voire impossible.

La bibliothèque boost::format tente de réunir le meilleur des deux mondes sur ce sujet.