cout.flush() utilité ?

Bonjour, je ne comprends pas le code suivant:

Code:

---

1 2 3 4 5 6 7

int main() { for(int i = 0; i < 100000 ; i++) { cout << i << '\r'; cout.flush(); } }

---

J'ai tester avec le flush() et sans, mais il n'y a aucune différence, quelqu'un pourrait-il donc m'expliquer? Merci !

Sur quelle plate-forme as-tu testé?

J'ai testé sur windows 7, avec code::blocks

flush sert à forcer l'écriture, c'est utile parce qu'en pratique, cout contient un buffer interne.
Ce buffer est effectivement vidé vers l'écran (ou autre chose) lors du flush ou d'un std::endl. Il l'est aussi "quand il est plein" et, je crois, "dès qu'une occasion se présente".

En pratique, tu n'en verras l'effet a peu près qu'en une seule occasion: quand tu utilises cout et cerr.
Par exemple, avec ce code:

Code:

---

1 2 3 4 5 6 7

try { cout <<"une grande phrase\n"; throw 1; } (catch int i) { cerr << "plantage"<<endl; } cout << "reprise" << endl;

---

Il est possible que ton écran montre ceci:

une grande phrase
plantage
reprise

ou cela:

plantage
une grande phrase
reprise

l'effet pervers, c'est que tu peux aussi ne jamais voir un message:

Code:

---

1 2 3 4 5

int main() { cout <<"une grande phrase"; throw 1; return 0; }

---

Ici, comme il n'y a pas de flush, le message peut ne pas être montré.


ps: on ne lance pas un int sans une bonne raison. ici, la concision de l'exemple.

Note que flush peut être utlisé sur un autre flux que cout. On peut utliser std::flush comme on utilise std::endl. D''ailleurs, utiliser std::endl effectue un flush. S'en servir peut avoir une réelle utilité : si la sortie de ton programme est consommée par un autre, souvent tu ne voudras pas que le buffer retarde l'écriture, donc tu vas flusher.

Je vous remercie pour vos réponse, ça m'aide beaucoup.
J'ai essayé ce code ci:

Code:

---

1 2 3 4 5

int main() { cout <<"une grande phrase"; throw 1; return 0; }

---

Et pourtant le message s'affiche quand même, pourquoi?
Vous avez dit aussi que flush vide le buffer vers l'écran, mais même sans flush le buffer est vidé vers l'écran, du coup, les explications se contredisent avec les exemples, et je suis confus.

Sous Windows, la console tend à être mise à jour instantanément. Il n'en est généralement pas de même sur les terminaux *n*x.

L'usage de flush permet de garantir que le message sera affiché avant de passer à la suite du programme.
Quand il n'est pas fait, on n'a pas de certitude, donc il vaut mieux s'attendre à ce que ce ne soit pas fait.
Cela n'empêche pas que ça "tombe en marche", et que le message soit affiché. C'est juste de la chance, plus ou moins reproductible.

Super je vous remercie pour tout ! J'ai enfin compris

J'ai entendu dire que lire sur cin causait automatiquement un flush de cout. Est-ce vrai?

Salut

Citation:

---

Envoyé par Médinoc

J'ai entendu dire que lire sur cin causait automatiquement un flush de cout. Est-ce vrai?

---

En tout cas, l'entrée standard est connectée "en droite ligne" avec la sorite standard : l'affichage de ce que tu introduis avant même d'avoir enfoncé <enter> est là pour le prouver ;)

De là à imaginer qu'elle cause un flush -- ne serait-ce que pour s'assurer que le message est correctement affiché avant que l'utilisateur n'enfonce une touche -- il n'y a qu'un pas, mais à mon niveau, cela reste pure spéculation ;)

Hello

Citation:

---

Envoyé par koala01

En tout cas, l'entrée standard est connectée "en droite ligne" avec la sorite standard : l'affichage de ce que tu introduis avant même d'avoir enfoncé <enter> est là pour le prouver ;)

---

Non, ce n'est pas le cas ! Il faut se méfier, ce n'est pas parce que le terminal affiche quelque chose que cela provient de la sortie standard. Exemple: le sortie d'erreur. Autre exemple:

Code:

---

1 2 3 4

#!/bin/bash echo hello read -p "Type something " echo world

---

Code:

---

./test.sh > test.txt

---

Affiche "Type something", on tape quelque chose, on appuie sur entrée, le script s'arrête. Le fichier résultant test.txt ne contient ni le prompt ni ce qu'on a tapé sur l'entrée standard, bien que ça se soit affiché.

Edit:Ca ne prouve pas ceci étant dit, que lire cin ne flush pas cout.

Et puis, l'écho est local.
Ce dont je parlais était du oui-dire soi-disant garanti par la norme, pour éviter des déboires rencontrées en C. Mais je n'ai pas la norme C++ sous les yeux...

Sur Unix, read/write sont non bufferisé, fread et fwrite le sont par défaut. fread/fwrite sont bien du C standard, mais read/write ne le sont pas. On peut flusher avec fflush. Selon le standard, la réponse est classique : ça dépend :mrgreen:.

Bon, je pense avoir trouvé de quoi il retourne:

Citation:

---

Envoyé par C++11, book of Input/Output library, verse 27.4.2.2

After the object cin is initialized, cin.tie() returns &cout.

---

std::basic_ios::tie

Edit: Ah, les quotes sont maintenant toujours en italique, même quand on ne précise pas l'auteur...

Et ce qui réalise la synchronisation avec l'élément tied, c'est la construction d'une instance de la classe Sentry :

Citation:

---

Envoyé par Le standard, 27.7.2.1.3 Class basic_istream::sentry

Effects: If is.good() is false, calls is.setstate(failbit). Otherwise, prepares for formatted or unformatted input. First, if is.tie() is not a null pointer, the function calls is.tie()->flush() to synchronize the output sequence with any associated external C stream. Except that this call can be suppressed if the put area of is.tie() is empty. Further an implementation is allowed to defer the call to flush until a call of is.rdbuf()->underflow() occurs. If no such call occurs before the sentry object is destroyed, the call to flush may be eliminated entirely.311

---