J'avoue passer beaucoup de temps sur ce code mais d'un point de vu implémentation d'un algorithme basique je le trouve intéressant pour me pencher dessus.
Donc quand j'exécute le code avec par exemple : Ch1 = jour ... Ch2 > bonjour ... ça fonctionne, le "trouve!" de la condition if s'affiche. Cependant quand j'exécute avec Ch1 = bon ... Ch2 = bonjour ... rien ne s'affiche
[...] > printf("nnEntrez la chaine a rech. Ch1 : ") ; > fgets(Ch1, 40, stdin) ; > printf("nEntrez la chaine Sujet. : ") ; > fgets(Suj, 80, stdin) ;
Dans le premier cas, tu compares "journ" et "bonjourn", dans le second "bonn", et "bonjourn". C'est le caractère 'n' qui empêche la seconde comparaison de fonctionner.
-- Richard
Le 01/12/2009 17:56, bpascal123@googlemail.com a écrit :
J'avoue passer beaucoup de temps sur ce code mais d'un point de vu
implémentation d'un algorithme basique je le trouve intéressant pour
me pencher dessus.
Donc quand j'exécute le code avec par exemple : Ch1 = jour ... Ch2 > bonjour ... ça fonctionne, le "trouve!" de la condition if s'affiche.
Cependant quand j'exécute avec Ch1 = bon ... Ch2 = bonjour ... rien
ne s'affiche
[...]
> printf("nnEntrez la chaine a rech. Ch1 : ") ;
> fgets(Ch1, 40, stdin) ;
> printf("nEntrez la chaine Sujet. : ") ;
> fgets(Suj, 80, stdin) ;
Dans le premier cas, tu compares "journ" et "bonjourn", dans le second
"bonn", et "bonjourn". C'est le caractère 'n' qui empêche la seconde
comparaison de fonctionner.
J'avoue passer beaucoup de temps sur ce code mais d'un point de vu implémentation d'un algorithme basique je le trouve intéressant pour me pencher dessus.
Donc quand j'exécute le code avec par exemple : Ch1 = jour ... Ch2 > bonjour ... ça fonctionne, le "trouve!" de la condition if s'affiche. Cependant quand j'exécute avec Ch1 = bon ... Ch2 = bonjour ... rien ne s'affiche
[...] > printf("nnEntrez la chaine a rech. Ch1 : ") ; > fgets(Ch1, 40, stdin) ; > printf("nEntrez la chaine Sujet. : ") ; > fgets(Suj, 80, stdin) ;
Dans le premier cas, tu compares "journ" et "bonjourn", dans le second "bonn", et "bonjourn". C'est le caractère 'n' qui empêche la seconde comparaison de fonctionner.
-- Richard
Hamiral
wrote:
On Dec 1, 7:26 pm, (Marc Espie) wrote:
In article ups.com>,
wrote:
Je ne souhaite pas faire appel aux pointeurs et aux fonctions autres comme fflush car d'après le tutorial, ça n'est pas nécessaire.
Mauvais tutoriel, changer de tutoriel.
C'est un conseil ou un ordre?
C'est vrai que ce tutoriel n'est pas beau. Il fait des suppositions sur la plateforme et l'implémentation, en plus des erreurs basiques (la fonction main déclarée simplement main() par exemple...). Je n'ai pas regardé plus loin, mais tu devrais quand même suivre les conseils (avisés) des personnes qui postent souvent ici (et ne sont donc pas des charlots).
Je ne souhaite pas faire appel aux pointeurs et aux fonctions autres
comme fflush car d'après le tutorial, ça n'est pas nécessaire.
Mauvais tutoriel, changer de tutoriel.
C'est un conseil ou un ordre?
C'est vrai que ce tutoriel n'est pas beau. Il fait des suppositions sur
la plateforme et l'implémentation, en plus des erreurs basiques (la
fonction main déclarée simplement main() par exemple...). Je n'ai pas
regardé plus loin, mais tu devrais quand même suivre les conseils
(avisés) des personnes qui postent souvent ici (et ne sont donc pas des
charlots).
Je ne souhaite pas faire appel aux pointeurs et aux fonctions autres comme fflush car d'après le tutorial, ça n'est pas nécessaire.
Mauvais tutoriel, changer de tutoriel.
C'est un conseil ou un ordre?
C'est vrai que ce tutoriel n'est pas beau. Il fait des suppositions sur la plateforme et l'implémentation, en plus des erreurs basiques (la fonction main déclarée simplement main() par exemple...). Je n'ai pas regardé plus loin, mais tu devrais quand même suivre les conseils (avisés) des personnes qui postent souvent ici (et ne sont donc pas des charlots).
Tu noteras que sur cette page tu trouves deux tutoriels écrits par Emmanuel Delahaye, qui poste pas mal ici-même, ce qui peut aider...
Ham
Samuel Devulder
Richard Delorme a écrit :
Dans le premier cas, tu compares "journ" et "bonjourn", dans le second "bonn", et "bonjourn". C'est le caractère 'n' qui empêche la seconde comparaison de fonctionner.
Bravo à toi et Lucas pour pointer le vrai pb du code de bpascal123.
Je me demande si bpascal123 a accès à un débuggeur ligne à ligne? Avec cet outil indispensable il aurait vite compris pourquoi son prog semblait ne pas marcher comme il le voulait.
Finalement, le code est bon et le bug se situe entre l'interface chaise-clavier.
sam.
Richard Delorme a écrit :
Dans le premier cas, tu compares "journ" et "bonjourn", dans le second
"bonn", et "bonjourn". C'est le caractère 'n' qui empêche la seconde
comparaison de fonctionner.
Bravo à toi et Lucas pour pointer le vrai pb du code de bpascal123.
Je me demande si bpascal123 a accès à un débuggeur ligne à ligne? Avec
cet outil indispensable il aurait vite compris pourquoi son prog
semblait ne pas marcher comme il le voulait.
Finalement, le code est bon et le bug se situe entre l'interface
chaise-clavier.
Dans le premier cas, tu compares "journ" et "bonjourn", dans le second "bonn", et "bonjourn". C'est le caractère 'n' qui empêche la seconde comparaison de fonctionner.
Bravo à toi et Lucas pour pointer le vrai pb du code de bpascal123.
Je me demande si bpascal123 a accès à un débuggeur ligne à ligne? Avec cet outil indispensable il aurait vite compris pourquoi son prog semblait ne pas marcher comme il le voulait.
Finalement, le code est bon et le bug se situe entre l'interface chaise-clavier.
sam.
bpascal123
On Dec 2, 12:14 pm, Richard Delorme wrote:
Le 01/12/2009 17:56, a écrit :
> J'avoue passer beaucoup de temps sur ce code mais d'un point de vu > implémentation d'un algorithme basique je le trouve intéressant pou r > me pencher dessus.
> Donc quand j'exécute le code avec par exemple : Ch1 = jour ... Ch2 = > bonjour ... ça fonctionne, le "trouve!" de la condition if s'affiche. > Cependant quand j'exécute avec Ch1 = bon ... Ch2 = bonjour ... r ien > ne s'affiche
[...] > printf("nnEntrez la chaine a rech. Ch1 : ") ; > fgets(Ch1, 40, stdin) ; > printf("nEntrez la chaine Sujet. : ") ; > fgets(Suj, 80, stdin) ;
Dans le premier cas, tu compares "journ" et "bonjourn", dans le second "bonn", et "bonjourn". C'est le caractère 'n' qui empêche la secon de comparaison de fonctionner.
-- Richard
Réponse très explicite pour qui veut comprendre le manque de rigueur sur mon code au niveau des E/S. Merci aussi pour le distingo entre saisir une donnée et exécuter un programme...
Au sujet des E/S, dans une autre discussion, il m'a été conseillé de ne pas inclure 'n' à la fin de printf, ex. : "printf("nBonsoirn") ; car le 'n' de fin est pris en compte dans le buffer pour le fgets suivant.Par conséquent, je me suis mis à coder avec 'n' en début et pas en fin : "printf("nBonsoir") ; et ligne suivante (selon l'affichage pour plus de clarté) printf("nn") afin d'éviter que le 'n' de printf se répercute sur la prochaine saisie. Peine perdue, j'avais oublié que la saisie côté utilisateur est également prise e n compte.
Parmi les réponses, une personne soutient que fflush est indispensable. Je comprends que cette fonction agit comme on tire sur une chasse d'eau, évacue tout ce qui se trouve en buffer. Il paraît que ce n'est pas sans inconvénient.
Est-ce que tout simplement : while(getchar() != 'n') ne peut pas suffire à cette situation?
J'arrête là, j'ai une grippe, certainement h1n1, ca sera la 2ème fois donc je ne dois pas m'exprimer avec clarté ...demande votre indulgence.
Pascal
On Dec 2, 12:14 pm, Richard Delorme <abu...@nospam.fr> wrote:
Le 01/12/2009 17:56, bpascal...@googlemail.com a écrit :
> J'avoue passer beaucoup de temps sur ce code mais d'un point de vu
> implémentation d'un algorithme basique je le trouve intéressant pou r
> me pencher dessus.
> Donc quand j'exécute le code avec par exemple : Ch1 = jour ... Ch2 =
> bonjour ... ça fonctionne, le "trouve!" de la condition if s'affiche.
> Cependant quand j'exécute avec Ch1 = bon ... Ch2 = bonjour ... r ien
> ne s'affiche
[...]
> printf("nnEntrez la chaine a rech. Ch1 : ") ;
> fgets(Ch1, 40, stdin) ;
> printf("nEntrez la chaine Sujet. : ") ;
> fgets(Suj, 80, stdin) ;
Dans le premier cas, tu compares "journ" et "bonjourn", dans le second
"bonn", et "bonjourn". C'est le caractère 'n' qui empêche la secon de
comparaison de fonctionner.
--
Richard
Réponse très explicite pour qui veut comprendre le manque de rigueur
sur mon code au niveau des E/S.
Merci aussi pour le distingo entre saisir une donnée et exécuter un
programme...
Au sujet des E/S, dans une autre discussion, il m'a été conseillé de
ne pas inclure 'n' à la fin de printf, ex. : "printf("nBonsoirn") ;
car le 'n' de fin est pris en compte dans le buffer pour le fgets
suivant.Par conséquent, je me suis mis à coder avec 'n' en début et
pas en fin : "printf("nBonsoir") ; et ligne suivante (selon
l'affichage pour plus de clarté) printf("nn") afin d'éviter que le
'n' de printf se répercute sur la prochaine saisie. Peine perdue,
j'avais oublié que la saisie côté utilisateur est également prise e n
compte.
Parmi les réponses, une personne soutient que fflush est
indispensable. Je comprends que cette fonction agit comme on tire sur
une chasse d'eau, évacue tout ce qui se trouve en buffer. Il paraît
que ce n'est pas sans inconvénient.
Est-ce que tout simplement : while(getchar() != 'n') ne peut pas
suffire à cette situation?
J'arrête là, j'ai une grippe, certainement h1n1, ca sera la 2ème fois
donc je ne dois pas m'exprimer avec clarté ...demande votre
indulgence.
> J'avoue passer beaucoup de temps sur ce code mais d'un point de vu > implémentation d'un algorithme basique je le trouve intéressant pou r > me pencher dessus.
> Donc quand j'exécute le code avec par exemple : Ch1 = jour ... Ch2 = > bonjour ... ça fonctionne, le "trouve!" de la condition if s'affiche. > Cependant quand j'exécute avec Ch1 = bon ... Ch2 = bonjour ... r ien > ne s'affiche
[...] > printf("nnEntrez la chaine a rech. Ch1 : ") ; > fgets(Ch1, 40, stdin) ; > printf("nEntrez la chaine Sujet. : ") ; > fgets(Suj, 80, stdin) ;
Dans le premier cas, tu compares "journ" et "bonjourn", dans le second "bonn", et "bonjourn". C'est le caractère 'n' qui empêche la secon de comparaison de fonctionner.
-- Richard
Réponse très explicite pour qui veut comprendre le manque de rigueur sur mon code au niveau des E/S. Merci aussi pour le distingo entre saisir une donnée et exécuter un programme...
Au sujet des E/S, dans une autre discussion, il m'a été conseillé de ne pas inclure 'n' à la fin de printf, ex. : "printf("nBonsoirn") ; car le 'n' de fin est pris en compte dans le buffer pour le fgets suivant.Par conséquent, je me suis mis à coder avec 'n' en début et pas en fin : "printf("nBonsoir") ; et ligne suivante (selon l'affichage pour plus de clarté) printf("nn") afin d'éviter que le 'n' de printf se répercute sur la prochaine saisie. Peine perdue, j'avais oublié que la saisie côté utilisateur est également prise e n compte.
Parmi les réponses, une personne soutient que fflush est indispensable. Je comprends que cette fonction agit comme on tire sur une chasse d'eau, évacue tout ce qui se trouve en buffer. Il paraît que ce n'est pas sans inconvénient.
Est-ce que tout simplement : while(getchar() != 'n') ne peut pas suffire à cette situation?
J'arrête là, j'ai une grippe, certainement h1n1, ca sera la 2ème fois donc je ne dois pas m'exprimer avec clarté ...demande votre indulgence.
Pascal
bpascal123
> Finalement, le code est bon et le bug se situe entre l'interface chaise-clavier.
sam.
exact
> Finalement, le code est bon et le bug se situe entre l'interface
chaise-clavier.
> Finalement, le code est bon et le bug se situe entre l'interface chaise-clavier.
sam.
exact
espie
In article , wrote:
Parmi les réponses, une personne soutient que fflush est indispensable. Je comprends que cette fonction agit comme on tire sur une chasse d'eau, évacue tout ce qui se trouve en buffer. Il paraît que ce n'est pas sans inconvénient.
Est-ce que tout simplement : while(getchar() != 'n') ne peut pas suffire à cette situation?
Tu te melanges les pinceaux entre l'entree standard et la sortie standard. Celles-ci ne sont absolument pas liees, en particulier les tampons correspondants n'ont aucun rapport !
Que tu mettes ou non des 'n' sur stdout (donc dans printf) tu ne les reverras pas dans l'entree standard (en particulier pas dans getchar()).
Le fflush(stdout), c'est juste pour t'assurer que tu verras bien ton message si tu n'as pas mis de 'n' au bout, avant de demander une entree a l'utilisateur. Ca peut tomber en marche sans le fflush sur ton implementation, mais ca fait du code qui "ne marche pas vraiment", alors que c'est facile de faire portable. Reflexe: printf() suivi d'une entree -> fflush au milieu.
(une des raisons pour lesquelles ca peut marcher, c'est que ce petit detail a ete ameliore en C++, ou le langage explicite un lien entre cin et cout, qui fait que ce genre de probleme ne s'y produit plus. Si ton compilateur "partage" sa bibliotheque entre C et C++, il se peut que les programmeurs aient garde ce lien. Il n'est pas *necessaire* en C, mais il n'est pas *interdit* non plus.)
In article <966f9ea0-17c2-497e-b82b-72a3e22fea0d@m3g2000yqf.googlegroups.com>,
bpascal123@googlemail.com <bpascal123@googlemail.com> wrote:
Parmi les réponses, une personne soutient que fflush est
indispensable. Je comprends que cette fonction agit comme on tire sur
une chasse d'eau, évacue tout ce qui se trouve en buffer. Il paraît
que ce n'est pas sans inconvénient.
Est-ce que tout simplement : while(getchar() != 'n') ne peut pas
suffire à cette situation?
Tu te melanges les pinceaux entre l'entree standard et la sortie standard.
Celles-ci ne sont absolument pas liees, en particulier les tampons
correspondants n'ont aucun rapport !
Que tu mettes ou non des 'n' sur stdout (donc dans printf) tu ne les
reverras pas dans l'entree standard (en particulier pas dans getchar()).
Le fflush(stdout), c'est juste pour t'assurer que tu verras bien ton
message si tu n'as pas mis de 'n' au bout, avant de demander une entree
a l'utilisateur. Ca peut tomber en marche sans le fflush sur ton
implementation, mais ca fait du code qui "ne marche pas vraiment", alors
que c'est facile de faire portable. Reflexe:
printf() suivi d'une entree -> fflush au milieu.
(une des raisons pour lesquelles ca peut marcher, c'est que ce petit detail
a ete ameliore en C++, ou le langage explicite un lien entre cin et cout,
qui fait que ce genre de probleme ne s'y produit plus.
Si ton compilateur "partage" sa bibliotheque entre C et C++, il se peut
que les programmeurs aient garde ce lien. Il n'est pas *necessaire* en C,
mais il n'est pas *interdit* non plus.)
Parmi les réponses, une personne soutient que fflush est indispensable. Je comprends que cette fonction agit comme on tire sur une chasse d'eau, évacue tout ce qui se trouve en buffer. Il paraît que ce n'est pas sans inconvénient.
Est-ce que tout simplement : while(getchar() != 'n') ne peut pas suffire à cette situation?
Tu te melanges les pinceaux entre l'entree standard et la sortie standard. Celles-ci ne sont absolument pas liees, en particulier les tampons correspondants n'ont aucun rapport !
Que tu mettes ou non des 'n' sur stdout (donc dans printf) tu ne les reverras pas dans l'entree standard (en particulier pas dans getchar()).
Le fflush(stdout), c'est juste pour t'assurer que tu verras bien ton message si tu n'as pas mis de 'n' au bout, avant de demander une entree a l'utilisateur. Ca peut tomber en marche sans le fflush sur ton implementation, mais ca fait du code qui "ne marche pas vraiment", alors que c'est facile de faire portable. Reflexe: printf() suivi d'une entree -> fflush au milieu.
(une des raisons pour lesquelles ca peut marcher, c'est que ce petit detail a ete ameliore en C++, ou le langage explicite un lien entre cin et cout, qui fait que ce genre de probleme ne s'y produit plus. Si ton compilateur "partage" sa bibliotheque entre C et C++, il se peut que les programmeurs aient garde ce lien. Il n'est pas *necessaire* en C, mais il n'est pas *interdit* non plus.)
Antoine Leca
écrivit :
Au sujet des E/S, dans une autre discussion, il m'a été conseillé de ne pas inclure 'n' à la fin de printf, ex. : "printf("nBonsoirn") ; car le 'n' de fin est pris en compte dans le buffer pour le fgets suivant.
Soit le conseil est mauvais, soit tu as mal compris. En fait, et le guide que tu as cité (pour ce que j'en ai vu) suit cette même voie, il vaut mieux utiliser systématiquement n à la fin de chaque groupe émis ; pas forcément chaque appel à printf(), mais sûrement avant de passer à autre chose comme par exemple attendre d'autres données de la part de l'utilisateur.
Parmi les réponses, une personne soutient que fflush est indispensable.
Là encore, il me semble que tu interprètes incorrectement. J'ai lu au moins trois personnes soutenir que fflush() doit être systématiquement utilisé _quand il n'y a pas de n à la fin du format de printf_.
Je comprends que cette fonction agit comme on tire sur une chasse d'eau, évacue tout ce qui se trouve en buffer. Il paraît que ce n'est pas sans inconvénient.
Peux-tu approfondir cette idée ?
Est-ce que tout simplement : while(getchar() != 'n') ne peut pas suffire à cette situation?
getchar() agit sur les données entrées ; printf() sur les données émises. Il n'y a pas de lien (pour ce qui concerne le C) entre les deux. Le fait que les caractères puissent t'apparaître mélangés à l'écran est dû à une interférence de ton système, qui duplique sur l'écran tous les caractères que tu tapes. Mais ce n'est pas obligatoire, c'est juste plus pratique dans la plupart des cas, c'est donc pour cela que c'est la situation par défaut quand tu travailles avec une ligne de commandes.
Soignes toi bien.
Antoine
bpascal123@googlemail.com écrivit :
Au sujet des E/S, dans une autre discussion, il m'a été conseillé de
ne pas inclure 'n' à la fin de printf, ex. : "printf("nBonsoirn") ;
car le 'n' de fin est pris en compte dans le buffer pour le fgets
suivant.
Soit le conseil est mauvais, soit tu as mal compris.
En fait, et le guide que tu as cité (pour ce que j'en ai vu) suit cette
même voie, il vaut mieux utiliser systématiquement n à la fin de chaque
groupe émis ; pas forcément chaque appel à printf(), mais sûrement avant
de passer à autre chose comme par exemple attendre d'autres données de
la part de l'utilisateur.
Parmi les réponses, une personne soutient que fflush est
indispensable.
Là encore, il me semble que tu interprètes incorrectement. J'ai lu au
moins trois personnes soutenir que fflush() doit être systématiquement
utilisé _quand il n'y a pas de n à la fin du format de printf_.
Je comprends que cette fonction agit comme on tire sur
une chasse d'eau, évacue tout ce qui se trouve en buffer. Il paraît
que ce n'est pas sans inconvénient.
Peux-tu approfondir cette idée ?
Est-ce que tout simplement : while(getchar() != 'n') ne peut pas
suffire à cette situation?
getchar() agit sur les données entrées ; printf() sur les données
émises. Il n'y a pas de lien (pour ce qui concerne le C) entre les deux.
Le fait que les caractères puissent t'apparaître mélangés à l'écran est
dû à une interférence de ton système, qui duplique sur l'écran tous les
caractères que tu tapes. Mais ce n'est pas obligatoire, c'est juste plus
pratique dans la plupart des cas, c'est donc pour cela que c'est la
situation par défaut quand tu travailles avec une ligne de commandes.
Au sujet des E/S, dans une autre discussion, il m'a été conseillé de ne pas inclure 'n' à la fin de printf, ex. : "printf("nBonsoirn") ; car le 'n' de fin est pris en compte dans le buffer pour le fgets suivant.
Soit le conseil est mauvais, soit tu as mal compris. En fait, et le guide que tu as cité (pour ce que j'en ai vu) suit cette même voie, il vaut mieux utiliser systématiquement n à la fin de chaque groupe émis ; pas forcément chaque appel à printf(), mais sûrement avant de passer à autre chose comme par exemple attendre d'autres données de la part de l'utilisateur.
Parmi les réponses, une personne soutient que fflush est indispensable.
Là encore, il me semble que tu interprètes incorrectement. J'ai lu au moins trois personnes soutenir que fflush() doit être systématiquement utilisé _quand il n'y a pas de n à la fin du format de printf_.
Je comprends que cette fonction agit comme on tire sur une chasse d'eau, évacue tout ce qui se trouve en buffer. Il paraît que ce n'est pas sans inconvénient.
Peux-tu approfondir cette idée ?
Est-ce que tout simplement : while(getchar() != 'n') ne peut pas suffire à cette situation?
getchar() agit sur les données entrées ; printf() sur les données émises. Il n'y a pas de lien (pour ce qui concerne le C) entre les deux. Le fait que les caractères puissent t'apparaître mélangés à l'écran est dû à une interférence de ton système, qui duplique sur l'écran tous les caractères que tu tapes. Mais ce n'est pas obligatoire, c'est juste plus pratique dans la plupart des cas, c'est donc pour cela que c'est la situation par défaut quand tu travailles avec une ligne de commandes.
Soignes toi bien.
Antoine
bpascal123
> Peux-tu approfondir cette idée ?
C'est en anglais, ça vient des personnes qui postent fréquemement sur comp.lang.c ;
You mean getchar rather than the second while. The trouble with using fflush(stdin) is that it is not portable. Some systems provide it as an extension but even if it is permitted, how can you be sure it does what you want? ... In fact the behavior of fflush(stdin) is undefined. Some implementations define useful behavior for it, but in general it should be avoided.
Apparemment d'après ce qui est dit fflush n'est pas toujours la solution qu'on veut. Mes connaissances et expériences sont très limitées à ce sujet (je n'ai pas encore vu fflush dans un exercice) et peut-être ça relève du détail pour un débutant...
> Est-ce que tout simplement : while(getchar() != 'n') ne peut pas > suffire à cette situation?
getchar() agit sur les données entrées ; printf() sur les données émises. Il n'y a pas de lien (pour ce qui concerne le C) entre les deux . Le fait que les caractères puissent t'apparaître mélangés à l' écran est dû à une interférence de ton système, qui duplique sur l'écran tous les caractères que tu tapes. Mais ce n'est pas obligatoire, c'est juste plu s pratique dans la plupart des cas, c'est donc pour cela que c'est la situation par défaut quand tu travailles avec une ligne de commandes.
En fait, je voulais comparer fflush et le vidage du tampon avec getchar (). Je ne sais pas si c'est ça que tu as expliqué.
Soignes toi bien.
Merci
Antoine
MErci pour votre aide, Pascal
> Peux-tu approfondir cette idée ?
C'est en anglais, ça vient des personnes qui postent fréquemement sur
comp.lang.c ;
You mean getchar rather than the second while. The trouble with using
fflush(stdin) is that it is not portable. Some systems provide it as
an extension but even if it is permitted, how can you be sure it does
what you want?
...
In fact the behavior of fflush(stdin) is undefined. Some
implementations define useful behavior for it, but in general it
should be avoided.
Apparemment d'après ce qui est dit fflush n'est pas toujours la
solution qu'on veut.
Mes connaissances et expériences sont très limitées à ce sujet (je
n'ai pas encore vu fflush dans un exercice) et peut-être ça relève du
détail pour un débutant...
> Est-ce que tout simplement : while(getchar() != 'n') ne peut pas
> suffire à cette situation?
getchar() agit sur les données entrées ; printf() sur les données
émises. Il n'y a pas de lien (pour ce qui concerne le C) entre les deux .
Le fait que les caractères puissent t'apparaître mélangés à l' écran est
dû à une interférence de ton système, qui duplique sur l'écran tous les
caractères que tu tapes. Mais ce n'est pas obligatoire, c'est juste plu s
pratique dans la plupart des cas, c'est donc pour cela que c'est la
situation par défaut quand tu travailles avec une ligne de commandes.
En fait, je voulais comparer fflush et le vidage du tampon avec getchar
(). Je ne sais pas si c'est ça que tu as expliqué.
C'est en anglais, ça vient des personnes qui postent fréquemement sur comp.lang.c ;
You mean getchar rather than the second while. The trouble with using fflush(stdin) is that it is not portable. Some systems provide it as an extension but even if it is permitted, how can you be sure it does what you want? ... In fact the behavior of fflush(stdin) is undefined. Some implementations define useful behavior for it, but in general it should be avoided.
Apparemment d'après ce qui est dit fflush n'est pas toujours la solution qu'on veut. Mes connaissances et expériences sont très limitées à ce sujet (je n'ai pas encore vu fflush dans un exercice) et peut-être ça relève du détail pour un débutant...
> Est-ce que tout simplement : while(getchar() != 'n') ne peut pas > suffire à cette situation?
getchar() agit sur les données entrées ; printf() sur les données émises. Il n'y a pas de lien (pour ce qui concerne le C) entre les deux . Le fait que les caractères puissent t'apparaître mélangés à l' écran est dû à une interférence de ton système, qui duplique sur l'écran tous les caractères que tu tapes. Mais ce n'est pas obligatoire, c'est juste plu s pratique dans la plupart des cas, c'est donc pour cela que c'est la situation par défaut quand tu travailles avec une ligne de commandes.
En fait, je voulais comparer fflush et le vidage du tampon avec getchar (). Je ne sais pas si c'est ça que tu as expliqué.
Soignes toi bien.
Merci
Antoine
MErci pour votre aide, Pascal
Alexandre Bacquart
wrote:
Peux-tu approfondir cette idée ?
C'est en anglais, ça vient des personnes qui postent fréquemement sur comp.lang.c ;
You mean getchar rather than the second while. The trouble with using fflush(stdin) is that it is not portable. Some systems provide it as an extension but even if it is permitted, how can you be sure it does what you want? ... In fact the behavior of fflush(stdin) is undefined. Some implementations define useful behavior for it, but in general it should be avoided.
Apparemment d'après ce qui est dit fflush n'est pas toujours la solution qu'on veut.
Tu t'es mélangé les pinceaux. Quand on parlait de fflush(), on voulait parler de fflush(stdout) (et non pas fflush(stdin) qui a effectivement un comportement indéfini).
-- Alex
bpascal123@googlemail.com wrote:
Peux-tu approfondir cette idée ?
C'est en anglais, ça vient des personnes qui postent fréquemement sur
comp.lang.c ;
You mean getchar rather than the second while. The trouble with using
fflush(stdin) is that it is not portable. Some systems provide it as
an extension but even if it is permitted, how can you be sure it does
what you want?
...
In fact the behavior of fflush(stdin) is undefined. Some
implementations define useful behavior for it, but in general it
should be avoided.
Apparemment d'après ce qui est dit fflush n'est pas toujours la
solution qu'on veut.
Tu t'es mélangé les pinceaux. Quand on parlait de fflush(), on voulait
parler de fflush(stdout) (et non pas fflush(stdin) qui a effectivement
un comportement indéfini).
C'est en anglais, ça vient des personnes qui postent fréquemement sur comp.lang.c ;
You mean getchar rather than the second while. The trouble with using fflush(stdin) is that it is not portable. Some systems provide it as an extension but even if it is permitted, how can you be sure it does what you want? ... In fact the behavior of fflush(stdin) is undefined. Some implementations define useful behavior for it, but in general it should be avoided.
Apparemment d'après ce qui est dit fflush n'est pas toujours la solution qu'on veut.
Tu t'es mélangé les pinceaux. Quand on parlait de fflush(), on voulait parler de fflush(stdout) (et non pas fflush(stdin) qui a effectivement un comportement indéfini).
-- Alex
Antoine Leca
a écrit :
Peux-tu approfondir cette idée ?
... In fact the behavior of fflush(stdin) is undefined. Some implementations define useful behavior for it,
Oui, bonne remarque.
but in general it should be avoided.
Là je suis moins d'accord : si cela marche pour ton implémentation, pourquoi s'en priver ? Mais bon, c'est dans la ligne de comp.lang.c
Apparemment d'après ce qui est dit fflush n'est pas toujours la solution qu'on veut.
Avec stdin (ou plus généralement un flux entrant) : effectivement, fflush() ne fait pas toujours ce que l'on veut.
Mais on parlait de flux sortants et en particulier de la sortie normale (stdout), ou du moins c'est ce que j'avais compris.
En fait, je voulais comparer fflush et le vidage du tampon avec getchar (). Je ne sais pas si c'est ça que tu as expliqué.
Pas exactement ; mais c'est bien le sujet dont parle les commentaires en anglais : en effet, fflush() est destiné aux sorties, pas aux entrées ; et penser que fflush(stdin) va vider le tampon est un mirage de la symétrie apparente (mais pas réelle) des entrées-sorties en C : parfois cela marche, parfois non, donc il faut faire très attention.
Le reste de mon message reste d'actualité.
Antoine
bpascal123@googlemail.com a écrit :
Peux-tu approfondir cette idée ?
...
In fact the behavior of fflush(stdin) is undefined. Some
implementations define useful behavior for it,
Oui, bonne remarque.
but in general it should be avoided.
Là je suis moins d'accord : si cela marche pour ton implémentation,
pourquoi s'en priver ?
Mais bon, c'est dans la ligne de comp.lang.c
Apparemment d'après ce qui est dit fflush n'est pas toujours la
solution qu'on veut.
Avec stdin (ou plus généralement un flux entrant) : effectivement,
fflush() ne fait pas toujours ce que l'on veut.
Mais on parlait de flux sortants et en particulier de la sortie normale
(stdout), ou du moins c'est ce que j'avais compris.
En fait, je voulais comparer fflush et le vidage du tampon avec getchar
(). Je ne sais pas si c'est ça que tu as expliqué.
Pas exactement ; mais c'est bien le sujet dont parle les commentaires en
anglais : en effet, fflush() est destiné aux sorties, pas aux entrées ;
et penser que fflush(stdin) va vider le tampon est un mirage de la
symétrie apparente (mais pas réelle) des entrées-sorties en C : parfois
cela marche, parfois non, donc il faut faire très attention.
... In fact the behavior of fflush(stdin) is undefined. Some implementations define useful behavior for it,
Oui, bonne remarque.
but in general it should be avoided.
Là je suis moins d'accord : si cela marche pour ton implémentation, pourquoi s'en priver ? Mais bon, c'est dans la ligne de comp.lang.c
Apparemment d'après ce qui est dit fflush n'est pas toujours la solution qu'on veut.
Avec stdin (ou plus généralement un flux entrant) : effectivement, fflush() ne fait pas toujours ce que l'on veut.
Mais on parlait de flux sortants et en particulier de la sortie normale (stdout), ou du moins c'est ce que j'avais compris.
En fait, je voulais comparer fflush et le vidage du tampon avec getchar (). Je ne sais pas si c'est ça que tu as expliqué.
Pas exactement ; mais c'est bien le sujet dont parle les commentaires en anglais : en effet, fflush() est destiné aux sorties, pas aux entrées ; et penser que fflush(stdin) va vider le tampon est un mirage de la symétrie apparente (mais pas réelle) des entrées-sorties en C : parfois cela marche, parfois non, donc il faut faire très attention.
