Problème printf et \n

Bonjour à tous.
D'abord mon environnement w7+codeblocks+mingw32
Voici un petit programme qui fonctionne:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

#include<stdio.h> #include<stdlib.h> #include<string.h> int main(int argc, char *argv[]) { int i; char *adr; adr="123456789"; for(i=0; i<10; i++) { printf("%c\n",adr[i]); } return 0;   }

---

Le problème est :Si je supprime le \n dans le printf la compile se passe bien mais la fenêtre de console n'affiche que la ligne process returned....
Si je mets un printf("bo"); par exemple ,(bizarre ,il faut que le mot est au moins deux caractères), dans le code en amont le pb ne se pose plus,je peux supprimer le \n
Qu'en pensez vous ?
Merci de m'avoir consacré de votre temps

Salut,


En général le flux de sortie est bufférisé.
Si tu ne forces pas l'écriture il est possible que les données restent dans le buffer et ne soit pas réellement écrites.

Pour que les données soient affichées, il faut :

• Soit utiliser fflush(stdout) pour forcer l'affichage du contenu du buffer.
• Soit utiliser un "\n" qui va forcer l'écriture du buffer (c'est spécifique à stdout et stderr)
• Soit que le buffer ait atteint une certaine taille (taille qui peut varier selon plein de critères comme le système, le compilateur, etc.).
  :arrow: c'est sûrement la raison du printf("bo") qui fait "marcher" ton code...

En clair si tu veux supprimer les "\n" dans la boucle, rajoute un printf("\n") ou un fflush(stdout) avant la fin de ton programme...

a++

Citation:

---

Envoyé par adiGuba

Pour que les données soient affichées, il faut :

• Soit utiliser fflush(stdout) pour forcer l'affichage du contenu du buffer.
• Soit utiliser un "\n" qui va forcer l'écriture du buffer (c'est spécifique à stdout et stderr)
• Soit que le buffer ait atteint une certaine taille (taille qui peut varier selon plein de critères comme le système, le compilateur, etc.).
  :arrow: c'est sûrement la raison du printf("bo") qui fait "marcher" ton code...

---

La fermeture du FILE * vide aussi le buffer.
Mais cela m'étonne que Windows ne flush pas stdout lors d'une sortie sans erreur d'un programme. :koi:

Citation:

---

Envoyé par Neckara

La fermeture du FILE * vide aussi le buffer.

---

En effet.
J'ai pas pensé à lui car on ferme rarement stdout ;)

Citation:

---

Envoyé par Neckara

Mais cela m'étonne que Windows ne flush pas stdout lors d'une sortie sans erreur d'un programme. :koi:

---

C'est le genre de comportement qui peut dépendre de plein de chose, comme l'OS ou le compilateur...

Donc perso cela ne m'étonne pas vraiment...

a++

Hello,

Citation:

---

Envoyé par adiGuba

C'est le genre de comportement qui peut dépendre de plein de chose, comme l'OS ou le compilateur...

---

Euh non, tout de même, le vidage sur fermeture d'un fichier est quand même quelque chose que l'on est en droit d'attendre de toute implémentation qui se respecte. Et cela est même précisé clairement par la norme :

Citation:

---

§5.1.2.2.3 Program termination

1. If the return type of the main function is a type compatible with int, a return from the
initial call to the main function is equivalent to calling the exit function with the value
returned by the main function as its argument;10) reaching the } that terminates the
main function returns a value of 0. If the return type is not compatible with int, the
termination status returned to the host environment is unspecified.

---

Citation:

---

§7.20.4.3 The exit function

4. Next, all open streams with unwritten buffered data are flushed, all open streams are
closed, and all files created by the tmpfile function are removed.

---

Citation:

---

§7.19.3 Files

4. A file may be disassociated from a controlling stream by closing the file. Output streams
are flushed (any unwritten buffer contents are transmitted to the host environment) before
the stream is disassociated from the file. The value of a pointer to a FILE object is
indeterminate after the associated file is closed (including the standard text streams).
Whether a file of zero length (on which no characters have been written by an output
stream) actually exists is implementation-defined.

---

@Obsidian : je suis d'accord avec toi : c'est dans la norme.
C'est juste que je ne serais pas vraiment étonné que le compilateur en question ne respecte pas cette norme...


[edit] Il peut y avoir une autre explication : le shell peut faire un retour en début de ligne (\t) et ainsi "écraser" les quelques caractères affichés à l'écran...


a++

Je suis repassé à la version 10.5 de CB et cela fonctionne
Merci à tous

Citation:

---

Envoyé par adiGuba

[edit] Il peut y avoir une autre explication : le shell peut faire un retour en début de ligne (\t) et ainsi "écraser" les quelques caractères affichés à l'écran..

---

C'est à cela que je pense également, et c'est un cas de figure déjà nettement plus courant. :-)

Citation:

---

Envoyé par adiGuba

[edit] Il peut y avoir une autre explication : le shell peut faire un retour en début de ligne (\t) et ainsi "écraser" les quelques caractères affichés à l'écran...

---

\r plutôt non?

Citation:

---

Envoyé par Neckara

\r plutôt non?

---

En fait je pensait plutôt à \f... mais j'avoue ne plus être sûr du tout (ca fait longtemps que je n'ai plus manipulé tout cela)...


a++

\r = carrier return (on revient au début de la ligne courante/retour chariot)
\n = linefeed/newline (on avance d'1 ligne exactement/déplacement en bas)

C'est bien le \r auquel tu pensais qui est rajouté en effet par le shell dans certains cas comme le dis Neckara !

Citation:

---

Envoyé par Metalman

C'est bien le \r auquel tu pensais qui est rajouté en effet par le shell dans certains cas comme le dis Neckara !

---

En effet oui j'ai confondus. C'est vieux tout çà :D

Le \f semble effacer l'écran.

a++

Citation:

---

Envoyé par adiGuba

Le \f semble effacer l'écran.

---

Plus précisément, « /f » correspond à « Form Feed » (soit « alimentation avec un feuillet, ou formulaire »). C'est un caractère du code ASCII qui sert littéralement à éjecter la feuille en cours d'une imprimante et avancer au début de la suivante, spécialement quand l'alimentation en papier d'une imprimante se fait en continu (avec des rouleaux à picots), mais pas nécessairement.

C'est un code qui est toujours reconnu. L'envoyer à une imprimante actuelle éjectera toujours la page pourvu que ladite imprimante soit toujours capable de traiter un flux de texte brut. Mais c'était déjà nécessaire sur les machines qui n'utilisaient pas de tube cathodique comme moniteur et qui communiquait à travers un téléscripteur.

Sur des moniteurs, justement, l'action équivalente à avancer en début de la page suivante consiste à effacer entièrement l'écran et à repositionner le curseur en haut à gauche. C'est ce qui se passe notamment sur les terminaux Vidéotex ou compatible (par exemple le Minitel et les ordinateurs Thomson).

À noter que ce caractère est le numéro 12 et qu'il correspond donc à Ctrl-L. Taper « Ctrl-L » sur un Minitel efface donc l'écran, mais c'est aussi pour cela qu'on peut aussi le faire depuis un Shell Unix, bien que le cheminement soit un peu moins direct (le Shell l'interprète comme une sollicitation de l'utilisateur et nettoie l'écran, que celui-ci soit compatible ou non).

Citation:

---

Envoyé par Metalman

C'est bien le \r auquel tu pensais qui est rajouté en effet par le shell dans certains cas comme le dis Neckara !

---

Sauf que \r n'efface pas la ligne en cours, elle repositionne juste le curseur en début de ligne.

Voir l'effet du code :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

#include <stdlib.h> #include <stdio.h> #include <stdint.h>   int main(void) { printf("toto"); putchar('\r'); putchar('J'); return 0; }

---

Oui... c'est pour ça que je l'ai écrit d'ailleurs ! :P

Citation:

---

\r = carrier return (on revient au début de la ligne courante/retour chariot)

---

Je n'ai pas parlé d'effacer la ligne !
L'effacement se fait avec le \n qui remplit d'espaces 1 ligne exactement quand on joue avec le mode canonique.