J'ai remplacé getch(0 par getche() dans la fonction gettoken() afin de voir
sur la fenêtre dos ce que j'écrivais.
La fonction gettoken() a été testé avec l'application dcl() de K&R page
122-123-124 et elle fonctionne normalement.
La fonction undcl(), elle ne fonctionne pas très bien en ce qu'il n'y a pas
moyen de la faire cesser avec la ligne:
while(gettoken() != EOF) dans main.
Voici un copie du programme donnée en exemple par KR chap 5.12
"Complicated declaration".
/*
undcl.c
"x is a function returning a pointer to an array of pointers to functions
returning char"
undcl convert word description to declaration
x () * [] * () char char (*(*x())[])()
void dcl(void);
void dirdcl(void);
int gettoken(void);
int tokentype; /* type of last token */
char token[MAXTOKEN]; /* last token string */
char name[MAXTOKEN]; /* identifyer name */
char datatype[MAXTOKEN]; /* data type = char, int, etc. */
char out[1000]; /* output string */
int gettoken(void){ /* return next token fonction commune a dcl() */
int c, getche(void);
void ungetch(int);
char *p = token;
Non. Car elles sont données dans le livre. Au chapitre 4 ou quelque par là, comme tu l'as expliqué dans un de tes messages précédents.
Et si tu remplaces "getch" par "lirecar", à la fois dans le source de la fonction et aussi dans l'appel dans "gettoken", le résultat doit être le même.
Et si tu utilises un getche à la place de getch, et bien il faut en fournir le source aussi, sinon cela peut ne pas marcher. ??
Et enfin, si à la place de la focntion décrite par Biran tu laisses le compilateur utiliser sa version à lui (parce qu'il y a une duplication de nom imprévue), et que le comportement des deux n'est pas exactement le même dans des cas limites, eh bien tu as exactement le comportement que tu nous a raconté.
En tapant TOUT ce que le bouquin te dis de taper, sans essayer de tirer au plus court. c'est ce que j'ai fait Les deux fonctions étant mentionné a 70 pages d'intervalle, je ne voyais pas
le rapport. Et puis on (ED) m'a accusé de vouloir réécrire strcpy y a pas si lontemps.
Maintenant, il y a une autre solution, mais ne l'appliques pas aveuglement ;-) #define EOF 13 ça c'est le genre de chose difficile pour moi
ça fonctionne.
Exercice: pourquoi? parce que je suis nul
Je n'ai pas la version française... ------ ça ne marche pas --------- #include <stdio.h>
#define BUFSIZE 100 char buf[BUFSIZE]; /* buffer for ungetch */ int bufp =0; /* next free posotion in bufp */ int getch(void); void ungetch(int);
/* get a possibly pushed back ) character*/ int getch(void){ return (buf>0) ? buf[--bufp] : getchar(); }
/* push back a character on input*/ void ungetch(int c){ if(bufp >= BUFSIZE) printf("ungetch: too many characters."); else buf[bufp++]; } ---------- ----------------
y aurait-t-il un #undef getch() #undef ungetch() à ajouter?
Non. Car elles sont données dans le livre. Au chapitre 4 ou quelque par
là, comme tu l'as expliqué dans un de tes messages précédents.
Et si tu remplaces "getch" par "lirecar", à la fois dans le source de la
fonction et aussi dans l'appel dans "gettoken", le résultat doit être le
même.
Et si tu utilises un getche à la place de getch, et bien il faut en
fournir
le source aussi, sinon cela peut ne pas marcher.
??
Et enfin, si à la place de la focntion décrite par Biran tu laisses le
compilateur utiliser sa version à lui (parce qu'il y a une duplication de
nom imprévue), et que le comportement des deux n'est pas exactement le
même
dans des cas limites, eh bien tu as exactement le comportement que tu nous
a
raconté.
En tapant TOUT ce que le bouquin te dis de taper, sans essayer de tirer au
plus court. c'est ce que j'ai fait
Les deux fonctions étant mentionné a 70 pages d'intervalle, je ne voyais pas
le rapport. Et puis on (ED) m'a accusé de vouloir réécrire strcpy y a pas si
lontemps.
Maintenant, il y a une autre solution, mais ne l'appliques pas aveuglement
;-)
#define EOF 13
ça c'est le genre de chose difficile pour moi
ça fonctionne.
Exercice: pourquoi?
parce que je suis nul
Je n'ai pas la version française...
------ ça ne marche pas ---------
#include <stdio.h>
#define BUFSIZE 100
char buf[BUFSIZE]; /* buffer for ungetch */
int bufp =0; /* next free posotion in bufp */
int getch(void);
void ungetch(int);
/* get a possibly pushed back ) character*/
int getch(void){
return (buf>0) ? buf[--bufp] : getchar();
}
/* push back a character on input*/
void ungetch(int c){
if(bufp >= BUFSIZE)
printf("ungetch: too many characters.");
else
buf[bufp++];
}
---------- ----------------
y aurait-t-il un #undef getch()
#undef ungetch() à ajouter?
Non. Car elles sont données dans le livre. Au chapitre 4 ou quelque par là, comme tu l'as expliqué dans un de tes messages précédents.
Et si tu remplaces "getch" par "lirecar", à la fois dans le source de la fonction et aussi dans l'appel dans "gettoken", le résultat doit être le même.
Et si tu utilises un getche à la place de getch, et bien il faut en fournir le source aussi, sinon cela peut ne pas marcher. ??
Et enfin, si à la place de la focntion décrite par Biran tu laisses le compilateur utiliser sa version à lui (parce qu'il y a une duplication de nom imprévue), et que le comportement des deux n'est pas exactement le même dans des cas limites, eh bien tu as exactement le comportement que tu nous a raconté.
En tapant TOUT ce que le bouquin te dis de taper, sans essayer de tirer au plus court. c'est ce que j'ai fait Les deux fonctions étant mentionné a 70 pages d'intervalle, je ne voyais pas
le rapport. Et puis on (ED) m'a accusé de vouloir réécrire strcpy y a pas si lontemps.
Maintenant, il y a une autre solution, mais ne l'appliques pas aveuglement ;-) #define EOF 13 ça c'est le genre de chose difficile pour moi
ça fonctionne.
Exercice: pourquoi? parce que je suis nul
Je n'ai pas la version française... ------ ça ne marche pas --------- #include <stdio.h>
#define BUFSIZE 100 char buf[BUFSIZE]; /* buffer for ungetch */ int bufp =0; /* next free posotion in bufp */ int getch(void); void ungetch(int);
/* get a possibly pushed back ) character*/ int getch(void){ return (buf>0) ? buf[--bufp] : getchar(); }
/* push back a character on input*/ void ungetch(int c){ if(bufp >= BUFSIZE) printf("ungetch: too many characters."); else buf[bufp++]; } ---------- ----------------
y aurait-t-il un #undef getch() #undef ungetch() à ajouter?
Emmanuel Delahaye
Antoine Leca wrote on 14/03/05 :
#define EOF 13
devrait marcher dans ton cas...
Comportement indéfini. EOF est un identificateur réservé.
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
Antoine Leca wrote on 14/03/05 :
#define EOF 13
devrait marcher dans ton cas...
Comportement indéfini. EOF est un identificateur réservé.
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
"Emmanuel Delahaye" a écrit dans le message de news:
| Antoine Leca wrote on 14/03/05 : | > #define EOF 13 | > | > devrait marcher dans ton cas... | | Comportement indéfini. EOF est un identificateur réservé. | | -- | Emmanuel | The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html | The C-library: http://www.dinkumware.com/refxc.html | | "C is a sharp tool" |
pourquoi 13 et non pas 12, etc.
"Emmanuel Delahaye" <emdel@YOURBRAnoos.fr> a écrit dans le message de news:
mn.75277d53e1bf2db4.15512@YOURBRAnoos.fr...
| Antoine Leca wrote on 14/03/05 :
| > #define EOF 13
| >
| > devrait marcher dans ton cas...
|
| Comportement indéfini. EOF est un identificateur réservé.
|
| --
| Emmanuel
| The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
| The C-library: http://www.dinkumware.com/refxc.html
|
| "C is a sharp tool"
|
"Emmanuel Delahaye" a écrit dans le message de news:
| Antoine Leca wrote on 14/03/05 : | > #define EOF 13 | > | > devrait marcher dans ton cas... | | Comportement indéfini. EOF est un identificateur réservé. | | -- | Emmanuel | The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html | The C-library: http://www.dinkumware.com/refxc.html | | "C is a sharp tool" |
Jean Pierre Daviau
int getone(void){ char c;
if(buf>0){ c = buf[--bufp]; printf("%c", c); return c; }else{ c = getchar(); printf("%c", c); return c; } }
int getone(void){
char c;
if(buf>0){
c = buf[--bufp];
printf("%c", c);
return c;
}else{
c = getchar();
printf("%c", c);
return c;
}
}
if(buf>0){ c = buf[--bufp]; printf("%c", c); return c; }else{ c = getchar(); printf("%c", c); return c; } }
Antoine Leca
En 1enZd.54152$, Jean Pierre Daviau va escriure:
pourquoi 13 et non pas 12, etc.
Parce que la touche Entrée a pour code 13 (contrôle-M).
getch() (dans la bibliothèque de Borland) retourne le code de la touche, sans aucune interprétation. Normalement c'est la même chose que getchar(), mais pas dans ce cas-là. Tu sais que les lignes des fichiers textes se terminent par n en C (ou sous Unix), et par CR+LF sous Windows. Et bien là c'est une différence du même genre. Sur les PC, la touche Entrée, héritage des machines à écrire électriques, émet le code de retour en marge gauche, "carriage return" en anglais ou CR, numéroté 13 dans le code ASCII. getchar() et toute la machinerie qui est dessous va transformer ce code 13 en n, qui va être à son tour manipulé par le getch() de Kernighan (vers la page 60) et transformé en EOF. Mais comme tu as court-circuité cela et utilisé le getch() de Borland, qui lui ne transforme rien, ton code voit un 13 là où il attend un EOF: d'où le truc que je "proposai". Le reste du temps, les codes ne sont pas manipulés et cela fonctionne parce que les attentes et les réalisations sont similaires, quand bien même le programme est complètement faux.
"Emmanuel Delahaye" a écrit dans le message de news:
Antoine Leca wrote on 14/03/05 :
#define EOF 13
Comportement indéfini. EOF est un identificateur réservé.
Seulement si <stdio.h> est #inclus; ce qui n'est pas clair dans le contexte.
De plus, un comportement indéfini (en général) n'empêche pas un programme particulier de fonctionner. C'est seulement si tu cherches à le porter (y compris à une version supérieure du compilateur) que tu dois corriger le problème.
Antoine
En 1enZd.54152$WM1.915428@wagner.videotron.net, Jean Pierre Daviau va
escriure:
pourquoi 13 et non pas 12, etc.
Parce que la touche Entrée a pour code 13 (contrôle-M).
getch() (dans la bibliothèque de Borland) retourne le code de la touche,
sans aucune interprétation. Normalement c'est la même chose que getchar(),
mais pas dans ce cas-là.
Tu sais que les lignes des fichiers textes se terminent par n en C (ou sous
Unix), et par CR+LF sous Windows. Et bien là c'est une différence du même
genre. Sur les PC, la touche Entrée, héritage des machines à écrire
électriques, émet le code de retour en marge gauche, "carriage return" en
anglais ou CR, numéroté 13 dans le code ASCII. getchar() et toute la
machinerie qui est dessous va transformer ce code 13 en n, qui va être à
son tour manipulé par le getch() de Kernighan (vers la page 60) et
transformé en EOF.
Mais comme tu as court-circuité cela et utilisé le getch() de Borland, qui
lui ne transforme rien, ton code voit un 13 là où il attend un EOF: d'où le
truc que je "proposai". Le reste du temps, les codes ne sont pas manipulés
et cela fonctionne parce que les attentes et les réalisations sont
similaires, quand bien même le programme est complètement faux.
"Emmanuel Delahaye" <emdel@YOURBRAnoos.fr> a écrit dans le message
de news: mn.75277d53e1bf2db4.15512@YOURBRAnoos.fr...
Antoine Leca wrote on 14/03/05 :
#define EOF 13
Comportement indéfini. EOF est un identificateur réservé.
Seulement si <stdio.h> est #inclus; ce qui n'est pas clair dans le contexte.
De plus, un comportement indéfini (en général) n'empêche pas un programme
particulier de fonctionner. C'est seulement si tu cherches à le porter (y
compris à une version supérieure du compilateur) que tu dois corriger le
problème.
Parce que la touche Entrée a pour code 13 (contrôle-M).
getch() (dans la bibliothèque de Borland) retourne le code de la touche, sans aucune interprétation. Normalement c'est la même chose que getchar(), mais pas dans ce cas-là. Tu sais que les lignes des fichiers textes se terminent par n en C (ou sous Unix), et par CR+LF sous Windows. Et bien là c'est une différence du même genre. Sur les PC, la touche Entrée, héritage des machines à écrire électriques, émet le code de retour en marge gauche, "carriage return" en anglais ou CR, numéroté 13 dans le code ASCII. getchar() et toute la machinerie qui est dessous va transformer ce code 13 en n, qui va être à son tour manipulé par le getch() de Kernighan (vers la page 60) et transformé en EOF. Mais comme tu as court-circuité cela et utilisé le getch() de Borland, qui lui ne transforme rien, ton code voit un 13 là où il attend un EOF: d'où le truc que je "proposai". Le reste du temps, les codes ne sont pas manipulés et cela fonctionne parce que les attentes et les réalisations sont similaires, quand bien même le programme est complètement faux.
"Emmanuel Delahaye" a écrit dans le message de news:
Antoine Leca wrote on 14/03/05 :
#define EOF 13
Comportement indéfini. EOF est un identificateur réservé.
Seulement si <stdio.h> est #inclus; ce qui n'est pas clair dans le contexte.
De plus, un comportement indéfini (en général) n'empêche pas un programme particulier de fonctionner. C'est seulement si tu cherches à le porter (y compris à une version supérieure du compilateur) que tu dois corriger le problème.
Antoine
Charlie Gordon
"Jean Pierre Daviau" wrote in message news:3goZd.22201$
int getone(void){ char c;
if(buf>0){ c = buf[--bufp]; printf("%c", c); return c; }else{ c = getchar(); printf("%c", c); return c; } }
Pas d'accord !
c doit pouvoir contenir toutes les valeurs renvoyées par getchar(), c'est à dire tous les unsigned char et la valeur EOF, il faut donc en faire un int.
le buffer global est de type char, il faut donc veiller à ce que les valeurs négatives de ce type soient converties en unsigned char avant conversion en int. C'est un probleme sur les plateformes ou le char est signé par défaut. Pour éviter ces problèmes subtils, je conseille de configurer le compilateur pour que les char soient non signés par défaut, mais ce n'est pas toujours possible.
Il y a une erreur sur le test : buf est le buffer, bufp est l'index entier. Notons que le test (buf > 0) n'a pas de sens, mais passe souvent sans produire de warning, 0 étant converti par le compilateur en pointeur null.
Utiliser printf() pour écrire un simple caractère sur stdout est "sous-optimal", qui plus est le comportement sur EOF dépend de la plateforme et n'est pas utile (y tréma par exemple ;-)
Pour que l'écho du caractère à la console ne soit pas retardé, voire oublié en fin de programme, il faut vider le buffer de stdio après chaque sortie avec fflush().
Il faut plutot mettre :
int getone (void) { int c;
if (bufp > 0) { c = (unsigned char)buf[--bufp]; return c; } else { c = getchar(); if (c != EOF) { putchar(c); fflush(stdout); } return c; } }
Mais notons que c'est pas très propre d'utiliser des variables globales avec de tels noms (buf, bufp) et particulièrement trompeur d'appeler un index entier bufp.
Chqrlie.
"Jean Pierre Daviau" <Once@WasEno.ugh> wrote in message
news:3goZd.22201$nT2.806997@weber.videotron.net...
int getone(void){
char c;
if(buf>0){
c = buf[--bufp];
printf("%c", c);
return c;
}else{
c = getchar();
printf("%c", c);
return c;
}
}
Pas d'accord !
c doit pouvoir contenir toutes les valeurs renvoyées par getchar(), c'est à dire
tous les unsigned char et la valeur EOF, il faut donc en faire un int.
le buffer global est de type char, il faut donc veiller à ce que les valeurs
négatives de ce type soient converties en unsigned char avant conversion en int.
C'est un probleme sur les plateformes ou le char est signé par défaut. Pour
éviter ces problèmes subtils, je conseille de configurer le compilateur pour que
les char soient non signés par défaut, mais ce n'est pas toujours possible.
Il y a une erreur sur le test : buf est le buffer, bufp est l'index entier.
Notons que le test (buf > 0) n'a pas de sens, mais passe souvent sans produire
de warning, 0 étant converti par le compilateur en pointeur null.
Utiliser printf() pour écrire un simple caractère sur stdout est "sous-optimal",
qui plus est le comportement sur EOF dépend de la plateforme et n'est pas utile
(y tréma par exemple ;-)
Pour que l'écho du caractère à la console ne soit pas retardé, voire oublié en
fin de programme, il faut vider le buffer de stdio après chaque sortie avec
fflush().
Il faut plutot mettre :
int getone (void) {
int c;
if (bufp > 0) {
c = (unsigned char)buf[--bufp];
return c;
} else {
c = getchar();
if (c != EOF) {
putchar(c);
fflush(stdout);
}
return c;
}
}
Mais notons que c'est pas très propre d'utiliser des variables globales avec de
tels noms (buf, bufp) et particulièrement trompeur d'appeler un index entier
bufp.
"Jean Pierre Daviau" wrote in message news:3goZd.22201$
int getone(void){ char c;
if(buf>0){ c = buf[--bufp]; printf("%c", c); return c; }else{ c = getchar(); printf("%c", c); return c; } }
Pas d'accord !
c doit pouvoir contenir toutes les valeurs renvoyées par getchar(), c'est à dire tous les unsigned char et la valeur EOF, il faut donc en faire un int.
le buffer global est de type char, il faut donc veiller à ce que les valeurs négatives de ce type soient converties en unsigned char avant conversion en int. C'est un probleme sur les plateformes ou le char est signé par défaut. Pour éviter ces problèmes subtils, je conseille de configurer le compilateur pour que les char soient non signés par défaut, mais ce n'est pas toujours possible.
Il y a une erreur sur le test : buf est le buffer, bufp est l'index entier. Notons que le test (buf > 0) n'a pas de sens, mais passe souvent sans produire de warning, 0 étant converti par le compilateur en pointeur null.
Utiliser printf() pour écrire un simple caractère sur stdout est "sous-optimal", qui plus est le comportement sur EOF dépend de la plateforme et n'est pas utile (y tréma par exemple ;-)
Pour que l'écho du caractère à la console ne soit pas retardé, voire oublié en fin de programme, il faut vider le buffer de stdio après chaque sortie avec fflush().
Il faut plutot mettre :
int getone (void) { int c;
if (bufp > 0) { c = (unsigned char)buf[--bufp]; return c; } else { c = getchar(); if (c != EOF) { putchar(c); fflush(stdout); } return c; } }
Mais notons que c'est pas très propre d'utiliser des variables globales avec de tels noms (buf, bufp) et particulièrement trompeur d'appeler un index entier bufp.
Chqrlie.
Jean Pierre Daviau
| Mais notons que c'est pas très propre d'utiliser des variables globales avec de | tels noms (buf, bufp) et particulièrement trompeur d'appeler un index entier | bufp.
Il faut dire ça à K&R ha!
Merci
| Mais notons que c'est pas très propre d'utiliser des variables globales
avec de
| tels noms (buf, bufp) et particulièrement trompeur d'appeler un index
entier
| bufp.
| Mais notons que c'est pas très propre d'utiliser des variables globales avec de | tels noms (buf, bufp) et particulièrement trompeur d'appeler un index entier | bufp.
Il faut dire ça à K&R ha!
Merci
Jean Pierre Daviau
"Antoine Leca" a écrit dans le message de news: d166vf$d7v$ | En 1enZd.54152$, Jean Pierre Daviau va | escriure: | > pourquoi 13 et non pas 12, etc. | | Parce que la touche Entrée a pour code 13 (contrôle-M). | | getch() (dans la bibliothèque de Borland) retourne le code de la touche, | sans aucune interprétation. Normalement c'est la même chose que getchar(), | mais pas dans ce cas-là. | Tu sais que les lignes des fichiers textes se terminent par n en C (ou sous | Unix), et par CR+LF sous Windows. Et bien là c'est une différence du même | genre. Sur les PC, la touche Entrée, héritage des machines à écrire | électriques, émet le code de retour en marge gauche, "carriage return" en | anglais ou CR, numéroté 13 dans le code ASCII. getchar() et toute la | machinerie qui est dessous va transformer ce code 13 en n, qui va être à | son tour manipulé par le getch() de Kernighan (vers la page 60) et | transformé en EOF. | Mais comme tu as court-circuité cela et utilisé le getch() de Borland, qui | lui ne transforme rien, ton code voit un 13 là où il attend un EOF: d'où le | truc que je "proposai". Le reste du temps, les codes ne sont pas manipulés | et cela fonctionne parce que les attentes et les réalisations sont | similaires, quand bien même le programme est complètement faux. | | | > "Emmanuel Delahaye" a écrit dans le message | > de news: | >> Antoine Leca wrote on 14/03/05 : | >>> #define EOF 13 | >> | >> Comportement indéfini. EOF est un identificateur réservé. | | Seulement si <stdio.h> est #inclus; ce qui n'est pas clair dans le contexte. | | De plus, un comportement indéfini (en général) n'empêche pas un programme | particulier de fonctionner. C'est seulement si tu cherches à le porter (y | compris à une version supérieure du compilateur) que tu dois corriger le | problème. et bien alors
while(gettoken() != 'n'){
"Antoine Leca" <root@localhost.invalid> a écrit dans le message de news:
d166vf$d7v$1@shakotay.alphanet.ch...
| En 1enZd.54152$WM1.915428@wagner.videotron.net, Jean Pierre Daviau va
| escriure:
| > pourquoi 13 et non pas 12, etc.
|
| Parce que la touche Entrée a pour code 13 (contrôle-M).
|
| getch() (dans la bibliothèque de Borland) retourne le code de la touche,
| sans aucune interprétation. Normalement c'est la même chose que getchar(),
| mais pas dans ce cas-là.
| Tu sais que les lignes des fichiers textes se terminent par n en C (ou
sous
| Unix), et par CR+LF sous Windows. Et bien là c'est une différence du même
| genre. Sur les PC, la touche Entrée, héritage des machines à écrire
| électriques, émet le code de retour en marge gauche, "carriage return" en
| anglais ou CR, numéroté 13 dans le code ASCII. getchar() et toute la
| machinerie qui est dessous va transformer ce code 13 en n, qui va être à
| son tour manipulé par le getch() de Kernighan (vers la page 60) et
| transformé en EOF.
| Mais comme tu as court-circuité cela et utilisé le getch() de Borland, qui
| lui ne transforme rien, ton code voit un 13 là où il attend un EOF: d'où
le
| truc que je "proposai". Le reste du temps, les codes ne sont pas manipulés
| et cela fonctionne parce que les attentes et les réalisations sont
| similaires, quand bien même le programme est complètement faux.
|
|
| > "Emmanuel Delahaye" <emdel@YOURBRAnoos.fr> a écrit dans le message
| > de news: mn.75277d53e1bf2db4.15512@YOURBRAnoos.fr...
| >> Antoine Leca wrote on 14/03/05 :
| >>> #define EOF 13
| >>
| >> Comportement indéfini. EOF est un identificateur réservé.
|
| Seulement si <stdio.h> est #inclus; ce qui n'est pas clair dans le
contexte.
|
| De plus, un comportement indéfini (en général) n'empêche pas un programme
| particulier de fonctionner. C'est seulement si tu cherches à le porter (y
| compris à une version supérieure du compilateur) que tu dois corriger le
| problème.
et bien alors
"Antoine Leca" a écrit dans le message de news: d166vf$d7v$ | En 1enZd.54152$, Jean Pierre Daviau va | escriure: | > pourquoi 13 et non pas 12, etc. | | Parce que la touche Entrée a pour code 13 (contrôle-M). | | getch() (dans la bibliothèque de Borland) retourne le code de la touche, | sans aucune interprétation. Normalement c'est la même chose que getchar(), | mais pas dans ce cas-là. | Tu sais que les lignes des fichiers textes se terminent par n en C (ou sous | Unix), et par CR+LF sous Windows. Et bien là c'est une différence du même | genre. Sur les PC, la touche Entrée, héritage des machines à écrire | électriques, émet le code de retour en marge gauche, "carriage return" en | anglais ou CR, numéroté 13 dans le code ASCII. getchar() et toute la | machinerie qui est dessous va transformer ce code 13 en n, qui va être à | son tour manipulé par le getch() de Kernighan (vers la page 60) et | transformé en EOF. | Mais comme tu as court-circuité cela et utilisé le getch() de Borland, qui | lui ne transforme rien, ton code voit un 13 là où il attend un EOF: d'où le | truc que je "proposai". Le reste du temps, les codes ne sont pas manipulés | et cela fonctionne parce que les attentes et les réalisations sont | similaires, quand bien même le programme est complètement faux. | | | > "Emmanuel Delahaye" a écrit dans le message | > de news: | >> Antoine Leca wrote on 14/03/05 : | >>> #define EOF 13 | >> | >> Comportement indéfini. EOF est un identificateur réservé. | | Seulement si <stdio.h> est #inclus; ce qui n'est pas clair dans le contexte. | | De plus, un comportement indéfini (en général) n'empêche pas un programme | particulier de fonctionner. C'est seulement si tu cherches à le porter (y | compris à une version supérieure du compilateur) que tu dois corriger le | problème. et bien alors
while(gettoken() != 'n'){
Jean Pierre Daviau
YES Merci
N.B.: YES terme ado signifiant great géant merci cool enfin qué que chose qui fonctionne c'est beau la vie, etc. "Charlie Gordon" a écrit dans le message de news: d1672a$8oj$ | "Jean Pierre Daviau" wrote in message | news:3goZd.22201$ | > int getone(void){ | > char c; | > | > if(buf>0){ | > c = buf[--bufp]; | > printf("%c", c); | > return c; | > }else{ | > c = getchar(); | > printf("%c", c); | > return c; | > } | > } | | Pas d'accord ! | | c doit pouvoir contenir toutes les valeurs renvoyées par getchar(), c'est à dire | tous les unsigned char et la valeur EOF, il faut donc en faire un int. | | le buffer global est de type char, il faut donc veiller à ce que les valeurs | négatives de ce type soient converties en unsigned char avant conversion en int. | C'est un probleme sur les plateformes ou le char est signé par défaut. Pour | éviter ces problèmes subtils, je conseille de configurer le compilateur pour que | les char soient non signés par défaut, mais ce n'est pas toujours possible. | | Il y a une erreur sur le test : buf est le buffer, bufp est l'index entier. | Notons que le test (buf > 0) n'a pas de sens, mais passe souvent sans produire | de warning, 0 étant converti par le compilateur en pointeur null. | | Utiliser printf() pour écrire un simple caractère sur stdout est "sous-optimal", | qui plus est le comportement sur EOF dépend de la plateforme et n'est pas utile | (y tréma par exemple ;-) | | Pour que l'écho du caractère à la console ne soit pas retardé, voire oublié en | fin de programme, il faut vider le buffer de stdio après chaque sortie avec | fflush(). | | Il faut plutot mettre : | | int getone (void) { | int c; | | if (bufp > 0) { | c = (unsigned char)buf[--bufp]; | return c; | } else { | c = getchar(); | if (c != EOF) { | putchar(c); | fflush(stdout); | } | return c; | } | } | | Mais notons que c'est pas très propre d'utiliser des variables globales avec de | tels noms (buf, bufp) et particulièrement trompeur d'appeler un index entier | bufp. | | Chqrlie. | |
YES
Merci
N.B.: YES terme ado signifiant great géant merci cool enfin qué que chose
qui fonctionne c'est beau la vie, etc.
"Charlie Gordon" <news@chqrlie.org> a écrit dans le message de news:
d1672a$8oj$1@reader1.imaginet.fr...
| "Jean Pierre Daviau" <Once@WasEno.ugh> wrote in message
| news:3goZd.22201$nT2.806997@weber.videotron.net...
| > int getone(void){
| > char c;
| >
| > if(buf>0){
| > c = buf[--bufp];
| > printf("%c", c);
| > return c;
| > }else{
| > c = getchar();
| > printf("%c", c);
| > return c;
| > }
| > }
|
| Pas d'accord !
|
| c doit pouvoir contenir toutes les valeurs renvoyées par getchar(), c'est
à dire
| tous les unsigned char et la valeur EOF, il faut donc en faire un int.
|
| le buffer global est de type char, il faut donc veiller à ce que les
valeurs
| négatives de ce type soient converties en unsigned char avant conversion
en int.
| C'est un probleme sur les plateformes ou le char est signé par défaut.
Pour
| éviter ces problèmes subtils, je conseille de configurer le compilateur
pour que
| les char soient non signés par défaut, mais ce n'est pas toujours
possible.
|
| Il y a une erreur sur le test : buf est le buffer, bufp est l'index
entier.
| Notons que le test (buf > 0) n'a pas de sens, mais passe souvent sans
produire
| de warning, 0 étant converti par le compilateur en pointeur null.
|
| Utiliser printf() pour écrire un simple caractère sur stdout est
"sous-optimal",
| qui plus est le comportement sur EOF dépend de la plateforme et n'est pas
utile
| (y tréma par exemple ;-)
|
| Pour que l'écho du caractère à la console ne soit pas retardé, voire
oublié en
| fin de programme, il faut vider le buffer de stdio après chaque sortie
avec
| fflush().
|
| Il faut plutot mettre :
|
| int getone (void) {
| int c;
|
| if (bufp > 0) {
| c = (unsigned char)buf[--bufp];
| return c;
| } else {
| c = getchar();
| if (c != EOF) {
| putchar(c);
| fflush(stdout);
| }
| return c;
| }
| }
|
| Mais notons que c'est pas très propre d'utiliser des variables globales
avec de
| tels noms (buf, bufp) et particulièrement trompeur d'appeler un index
entier
| bufp.
|
| Chqrlie.
|
|
N.B.: YES terme ado signifiant great géant merci cool enfin qué que chose qui fonctionne c'est beau la vie, etc. "Charlie Gordon" a écrit dans le message de news: d1672a$8oj$ | "Jean Pierre Daviau" wrote in message | news:3goZd.22201$ | > int getone(void){ | > char c; | > | > if(buf>0){ | > c = buf[--bufp]; | > printf("%c", c); | > return c; | > }else{ | > c = getchar(); | > printf("%c", c); | > return c; | > } | > } | | Pas d'accord ! | | c doit pouvoir contenir toutes les valeurs renvoyées par getchar(), c'est à dire | tous les unsigned char et la valeur EOF, il faut donc en faire un int. | | le buffer global est de type char, il faut donc veiller à ce que les valeurs | négatives de ce type soient converties en unsigned char avant conversion en int. | C'est un probleme sur les plateformes ou le char est signé par défaut. Pour | éviter ces problèmes subtils, je conseille de configurer le compilateur pour que | les char soient non signés par défaut, mais ce n'est pas toujours possible. | | Il y a une erreur sur le test : buf est le buffer, bufp est l'index entier. | Notons que le test (buf > 0) n'a pas de sens, mais passe souvent sans produire | de warning, 0 étant converti par le compilateur en pointeur null. | | Utiliser printf() pour écrire un simple caractère sur stdout est "sous-optimal", | qui plus est le comportement sur EOF dépend de la plateforme et n'est pas utile | (y tréma par exemple ;-) | | Pour que l'écho du caractère à la console ne soit pas retardé, voire oublié en | fin de programme, il faut vider le buffer de stdio après chaque sortie avec | fflush(). | | Il faut plutot mettre : | | int getone (void) { | int c; | | if (bufp > 0) { | c = (unsigned char)buf[--bufp]; | return c; | } else { | c = getchar(); | if (c != EOF) { | putchar(c); | fflush(stdout); | } | return c; | } | } | | Mais notons que c'est pas très propre d'utiliser des variables globales avec de | tels noms (buf, bufp) et particulièrement trompeur d'appeler un index entier | bufp. | | Chqrlie. | |