Discussion :

[torquemada]

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

Code :

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

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

[adiGuba]

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.).
  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++

[Neckara]

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.).
  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.

[adiGuba]

La fermeture du FILE * vide aussi le buffer.

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

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

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++

[Obsidian]

Hello,

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 :

§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.

§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.

§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.

[adiGuba]

@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++

[torquemada]

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