vider le buffer clavier

Version imprimable

19/06/2006, 12h25
Pragmateek

vider le buffer clavier
Salut!:D

Y a t'il stricte équivalence entre:
Code:

1 2 int c; while(scanf("%c",&c) && c!='\n' && c!=EOF);
et:
Code:

1 2 int c; while ((c = getchar()) != '\n' && c != EOF);
(cette méthode étant la plus élégante).
Autrement dit entre:
scanf("%c",&c) et c=getchar() ?

Merci.
19/06/2006, 12h29
KiLVaiDeN

Est-ce que tu cherches à savoir s'il y a équivalence sémantique ?

Je pense que c'est équivalent, par contre ça sera beaucoup plus rapide d'utiliser getchar car tu t'affranchies des vérifications de format de scanf ;)
19/06/2006, 12h34
ankou82

bonjour,

je crois que c est fflush(stdin)
19/06/2006, 12h39
joellel

Citation:

Envoyé par seriousme

Salut!:D

Y a t'il stricte équivalence entre:
scanf("%c",&c) et c=getchar() ?

Merci.

a priori, oui. Les deux lisent le premier caractère disponible dans le flux stdin.Tu peux toujours regarder ce que fait getchar(), c'est une macro définie dans stdio.h et non une fonction.
Ceci dit, je ne suis pas du tout sûre que EOF soit chargé dans c.
19/06/2006, 12h56
gege2061
Citation:

Envoyé par ankou82

je crois que c est fflush(stdin)

Non : :faq: Comment vider le buffer clavier ?
Citation:
Envoyé par seriousme

Code:

1 2 int c; while(scanf("%c",&c) && c!='\n' && c!=EOF);
J'ai comme un doute sur le fait que scanf stocke EOF dans c en cas de fin de fichier :

Citation:

Envoyé par man scanf

La valeur EOF est renvoyée si une erreur d'entrée a eu lieu avant toute conversion, par exemple une fin de fichier. Si une erreur fin-de-fichier se produit après que les conversions aient commencé, le nombre de conversions réussies sera renvoyé.
19/06/2006, 13h01
Pragmateek
Merci de vos réponses.
Je veux dire toutes les différences entre ces fonctions.
Donc:
-"getchar" plus rapide,
-problème(?) avec EOF avec "scanf"

Citation:

c'est une macro définie dans stdio.h et non une fonction.
Code:

1 2 3 4 5 6 __CRT_INLINE int __cdecl getchar (void) { return (--stdin->_cnt >= 0) ? (int) (unsigned char) *stdin->_ptr++ : _filbuf (stdin); }
Ce n'est pas une macro, juste une fonction inline.:roll:

Citation:
Envoyé par seriousme
Code:

1 2 3 4 5 6 __CRT_INLINE int __cdecl getchar (void) { return (--stdin->_cnt >= 0) ? (int) (unsigned char) *stdin->_ptr++ : _filbuf (stdin); }
Ce n'est pas une macro, juste une fonction inline.:roll:
Ca dépend des implémentations
Code:

1 2 #define getchar() getc(stdin)
:lol:

19/06/2006, 13h11
Foobar1329
Citation:

Envoyé par ankou82

bonjour,

je crois que c est fflush(stdin)

Nonnnn !!! :aie:

Pas portable.

Pour répondre à la question initiale, %c du scanf matche un caractère, pas un entier, même si ça marche le plus souvent de part la conversion du char * attendu vers le int * donné en argument. Mais cela ne marche pas : le '\n' n'est jamais lu sauf si spécifié dans la directive du format.

Rappel :

"Trailing white space (including new-line characters) is left unread unless matched by a directive. The success of literal matches and suppressed assignments is not directly determinable other than via the %n directive."

C'est possible d'utiliser scanf() pour flusher stdin, mais pour rude boys seulement (XP > 10 ans de C, et encore ...)
http://groups.google.fr/group/comp.l...0de88382?hl=fr

La plus belle solution reste
Code:

1 2 3 int c; while ((c = getchar()) != '\n' && c != EOF);
Pas de scan, de recherche du type attendu en fonction du spécifiateur de format, et de mise à jour de la varaible correspondante passée en argument dans ce cas => getchar() est bien plus efficace.

Et pas de flush sur l'entree standard avec fflush(), merci pour elle.

A+

hello

j ai retrouvé ce que j avais trouvé sur le net c etait :

Code:

1
2
3
4
5
6
7
8
9
void flush(void)
{
   int c;
 
   #ifdef _WIN32
      fflush(stdin);
   #elif defined(linux)
      while( (c=getchar())!='\n' && c!=EOF ); // lit le buffer jusqu'à ce qu'il soit vide
   #endif

ca marchait tres bien

Citation:
Envoyé par ankou82
hello

j ai retrouvé ce que j avais trouvé sur le net c etait :
Code:

1 2 3 4 5 6 7 8 9 void flush(void) { int c; #ifdef _WIN32 fflush(stdin); #elif defined(linux) while( (c=getchar())!='\n' && c!=EOF ); // lit le buffer jusqu'à ce qu'il soit vide #endif
ca marchait tres bien
De quelle source, car le bon programmeur aurait simplement écrit
Code:

1 2 3 4 5 void flush(void) { int c; while( (c=getchar())!='\n' && c!=EOF ); }
et ça marche sous Linux, Windows, MacOSX, AIX, Solaris, HP-UX, ce que tu veux qui a un vrai compilateur C et une vraie libc.

D'autre part, c'est très piégeux, car fflush(stdin), plus que d'être non portable, produit un comportement indéfini d'après la norme. Le fait qu'il soit défini avec l'implémentation de Microsoft est un non-respect de la norme par MS. Comme chez ces derniers ils ont fait de gros efforts au niveau de leur CRT (depuis VC .NET et plus encore pour VC2005, en même temps que de gros progrès par rapport à la norme C++) , il se pourrait bien que fflush(stdin) ne soit plus défini comme auparavant et produise donc un comportement indéfini. Et puis c'est laid toutes c'est directives préprocesseur dans le code, surtout quand il n'y en a pas besoin).

A+

19/06/2006, 14h41
Emmanuel Delahaye

Citation:

Envoyé par ankou82

bonjour,

je crois que c est fflush(stdin)

:mur: :furieux: :fessee: :pan: :alerte: :zekill: :scarymov: :sm: :marteau:

Citation:

Envoyé par ankou82

hello

j ai retrouvé ce que j avais trouvé sur le net c etait :

Code:

1
2
3
4
5
6
7
8
9
10
void flush(void)
{
   int c;
 
   #ifdef _WIN32
      fflush(stdin);
   #elif defined(linux)
      while( (c=getchar())!='\n' && c!=EOF ); // lit le buffer jusqu'à ce qu'il soit vide
   #endif 
}

ca marchait tres bien

Ca aussi :

Code:

1
2
3
4
5
6
7
void flush(void)
{
   int c;
 
   // lit le buffer jusqu'à ce qu'il soit vide
   while( (c=getchar())!='\n' && c!=EOF );
}

ou :

Code:

1
2
3
4
5
6
7
8
 
static void purge (FILE * fp)
{
   int c;
   while ((c = fgetc (fp)) != '\n' && c != EOF)
   {
   }
}

19/06/2006, 19h56
Pragmateek

Merci de toutes vos réponses et remarques.
Donc si on résume:
-"getchar" plus rapide,
-getchar plus souple: pas de problème en utilisant des "int" à la place de "char"
-problème avec EOF avec "scanf"
-"scanf" "vraie" fonction, getchar tantôt fonction tantôt macro.
C'est tout?
Y a t'il d'autres éléments interressant?
20/06/2006, 13h21
Pragmateek

Il n'y a vraiment rien d'autre à signaler?
20/06/2006, 13h24
Emmanuel Delahaye

Citation:

Envoyé par seriousme

Il n'y a vraiment rien d'autre à signaler?

Je ne pense pas. J'ai publié une solution basée sur l'expérience et les forums Usenet c.l.c. et f.c.l.c. Je ne pense pas qu'on puisse faire mieux.
20/06/2006, 13h34
Pragmateek

Pas seulement pour la purge mais plus généralement sur les différences entre "scanf" et "getchar".
20/06/2006, 13h41
Emmanuel Delahaye

Citation:

Envoyé par seriousme

Pas seulement pour la purge mais plus généralement sur les différences entre "scanf" et "getchar".

C'est quoi scanf() ? :mouarf:
20/06/2006, 16h06
Pragmateek
Pour le problème du EOF:

Code:

while(!feof(stdin)&& scanf("%c",&c) && c!='\n');

ne marche pas.
En effet ce test:
Code:

1 2 3 4 char c,c1,c2; printf("premier caractere\n"); scanf("%c",&c1); printf("%c %d\n",c1,feof(stdin));
Si on rentre:
a^z (ctrl+z)
affiche:
a 0
donc il n'a pas détecté le EOF.
Pourtant:
scanf("%c",&c1);/*prend le caractère a, il ne reste que le EOF*/
feof(stdin);/*regarde si le caractère restant est EOF*/
où est l'erreur de raisonnement?
20/06/2006, 16h10
Emmanuel Delahaye

Citation:

Envoyé par seriousme

Pour le problème du EOF:

Code:

while(!feof(stdin)&& scanf("%c",&c) && c!='\n');

ne marche pas.

Mais tu sort ça d'où ? feof() ne fait pas ce que tu crois :

http://emmanuel-delahaye.developpez....s.htm#fichiers

On t'a déjà donné les solutions qui fonctionnent. Tu cherches quoi exactement ? A réinventer la roue ?
20/06/2006, 16h34
Pragmateek

Citation:

Mais tu sort ça d'où ? feof() ne fait pas ce que tu crois :

le "man" dit:

Citation:

La fonction feof teste l'indicateur de fin de fichier concernant le flux pointé par stream

^Z simule cette fin de fichier, non?
Pourquoi n'est t'elle pas détectée?

Citation:

On t'a déjà donné les solutions qui fonctionnent

Ce n'est pas mon but ici.

Citation:

Tu cherches quoi exactement ?

A comprendre, c'est tout.

Citation:

A réinventer la roue ?

Une fois de plus non, la solution du "getchar" est de loin la meilleure.
20/06/2006, 16h43
Emmanuel Delahaye

Citation:

Envoyé par seriousme

A comprendre, c'est tout.

As-tu lu ceci et refait tous les exemples ?

http://emmanuel-delahaye.developpez.com/notes.htm#fgetc
20/06/2006, 17h41
Pragmateek

1 pièce(s) jointe(s)
Citation:

As-tu lu ceci et refait tous les exemples ?

Maintenant oui. :mrgreen:
Avec le code:
Code:

1 2 3 4 char c,c1,c2; printf("premier caractere\n"); scanf("%c",&c1); printf("%c %d\n",c1,feof(stdin));
Ce que je crois, mais qui est faux:

Pièce jointe 2098

Pourrais tu me dire où le raisonnement est faux, s'il te plaît?
Merci d'avance.
20/06/2006, 17h45
Emmanuel Delahaye

Citation:

Envoyé par seriousme

Pièce jointe 2098

Illisible...Tu peux refaire ce texte avec une police à chasse fixe.
20/06/2006, 17h51
Pragmateek

1 pièce(s) jointe(s)

Désolé.:oops:
Pièce jointe 2101
20/06/2006, 18h49
Emmanuel Delahaye

Citation:

Envoyé par seriousme

Désolé.:oops:
Pièce jointe 2101

Non. Il faut que utilise courrier ou lucida console...
20/06/2006, 19h23
Pragmateek

1 pièce(s) jointe(s)

Ca devrait être bon cette fois:

Pièce jointe 2102

Merci de ta patience.

Citation:

Envoyé par seriousme

Ca devrait être bon cette fois:

Pièce jointe 2102

Merci de ta patience.

Il suffisait de poster ça :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
1er "parcours":
+-----Etape-----+----Entrée clavier-----+-----Etat du buffer de stdin----+
|       0       |        (au début)     |             vide               |
|       1       |         ^z            |               ^z               |
+---------------+-----------------------+--------------------------------+
1)Dans ce cas "scanf("%c",&c1);" bloque en attendant une frappe clavier valide
+--------------+-------------------------+-------------------------------+
|       2      |          a              |                a^z            |
+--------------+-------------------------+-------------------------------+
2)la frappe est valide, "scanf("%c",&c1);" prélève le a
+---------------------+-------------------------------+------------------+
|          3          |                               |             ^z   |
+---------------------+-------------------------------+------------------+
 "feof" repère le "^z", ça affiche: "a 16" (donc EOF détecté), tout est normal.
 
Autre parcours:
+-----Etape-----+----Entrée clavier-----+-----Etat du buffer de stdin-----+
|            0  |        (au début)     |             vide                |
|            1  |         a^z           |              a^z                |
+--------------------+----------------------------+-----------------------+
1)Ici la frappe est valide donc "scanf("%c",&c1);" prélève le a.
+---------------+------------------------+-------------------------------+
|       2       |                        |               ^z              |
+---------------+------------------------+-------------------------------+ 
2)Mais l'affichage:a 0 (EOF non détecté) alors que devant se trouver dans le buffer.

Si j'ai bien compris,

Code:

scanf("%c", &c);

est une façon compliquée d'écrire

Code:

c = getchar();

Donc, je ne vois pas trop l'intérêt...

Ensuite, concernant feof(), il faut comprendre qu'il ne fait que montrer que la cause de la fin de lecture est 'Fin de fichier'. Il n'est mis à jour que si la fin de fichier s'est produite. L'état qu'il retourne avant n'est pas défini.

C'est la valeur retournée par la fonction de lecture qui sert à dire si celle-ci s'est interrompue ou non.

20/06/2006, 20h14
Pragmateek

Citation:

Il n'est mis à jour que si la fin de fichier s'est produite

Il ne consulte pas directement "stdin" mais des flags?

Citation:

la fin de fichier s'est produite

Si une autre fonction la rencontre, les flags sont mis à jour et c'est cela que "feof" détecte?
20/06/2006, 20h18
Emmanuel Delahaye

Citation:

Envoyé par seriousme

Il ne consulte pas directement "stdin" mais des flags?

Si une autre fonction la rencontre, les flags sont mis à jour et c'est cela que "feof" détecte?

Absolument. C'est fait pour identifier la cause de l'arrêt. Mais j'ai expliqué tout ça noir sur blanc dans mes articles, tu ne les a donc pas lus ? C'est désepérant...
20/06/2006, 20h24
Pragmateek

Citation:

tu ne les a donc pas lus ? C'est désepérant...

Je las ai lus mais ce comportement ne me semblait vraiment pas évident.

Citation:

Le langage C met à disposition les deux fonctions feof() et ferror() qu'il faut appeler après la boucle de lecture, mais avant la fermeture du
fichier.

Cette phrase est claire maintenant mais avant elle m'était complètement obscure, désolé.

Merci encore de tes explications et de ta patience.
20/06/2006, 21h16
Jean-Marc.Bourguet

Citation:

Envoyé par Emmanuel Delahaye

Ensuite, concernant feof(), il faut comprendre qu'il ne fait que montrer que la cause de la fin de lecture est 'Fin de fichier'. Il n'est mis à jour que si la fin de fichier s'est produite. L'état qu'il retourne avant n'est pas défini.

Mais si il est défini. Mais simplement la manière dont il est défini peut être surprenante pour ceux qui s'attendent à ce que feof soit prédictif.

feof() indique qu'on a tenté de lire après la fin du fichier. Cela peut être soit par une lecture de plusieurs caractères (fread, fscanf, fgets) auquel cas cette lecture peut ne pas avoir échoué, soit par une lecture d'un caractère auquel cas la lecture aura échoué.

Comme de toute manière une lecture sur un fichier qui retourne feof() échoue, la technique normale en C est de tenter des lectures jusqu'à ce qu'il y en a une qui échoue. Après on teste feof et ferror pour déterminer la cause de l'erreur (si aucun des deux n'est mis, c'est qu'on utilisait fscanf et qu'il y a une erreur de format, ferror indique qu'il y a eu une erreur de lecture donnée par l'OS, feof indique qu'on a atteinds la fin du fichier).
On peut effacer les deux conditions feof et ferror avec clearerr et retenter une lecture. Suivant la cause de l'erreur et l'OS, ça peut passer ou refaire une erreur de suite.
20/06/2006, 21h33
Pragmateek

Merci de ces précisions.

En fait pour que "scanf" enclenche le flag de EOF il faut le "forcer", c'est à dire mettre un ^z seul sinon il ne déclenche rien et se contente d'attendre une entrée valide.
C'est pour ça que le premier exemple enclenche le flag EOF et pas le second.

J'hésite à demander la raison de ce comportement.:roll::mouarf: