Salut a tous    
 
Voila, j'ai un petit souci avec un bout de code tout bete :
 

 
Le getchar n'attend pas la frappe d'une touche, il passe directement a la suite.
J'ai le meme probleme en utilisant getc(stdin) (qui est l'equivalent).
Je suis sous MDK 10.0, et ce qui m'ennuie, c'est qu'en testant le meme code sous FC2 tout passe nickel ...
 
J'ai essaye d'utiliser getch() avec curses.h, mais la j'ai l'erreur suivante a la compilation :
 

 
Vous avez une idee ?
 
Merci d'avance  
 
edit : la question est de savoir si cela viendrait de ma version de gcc ou d'autre chose ... et s'il existe une alternative permettant d'avoir le meme effet, sans avoir a recoder la fonction comme Taz l'a deja indique dans un autre post.

hein ? getchar / fgetc attende qu'on appuie sur entrée ... sinon, ça veut dire que tu as foiré un scanf/printf avant

Oups, me suis plante sur le message avant le getchar(), je corrige ;-)
 
J'ai eu la meme idee, concernant un eventuel scanf/printf foire en amont, bah j'ai recopie ce bout de code tout simple pour tester, et bien meme avec uniquement ca dans le main, le prog se termine direct, sans attendre de touche ...
 
Je viens de me rendre compte que j'ai egalement le meme probleme avec :

ouais, ben alors ça, c'est la marne, il lit 1 caractère, et après il te reste un '\n' que tu as saisis, mais pas lu. c'est cet '\n' que tu récupères avec ton getchar suivant

Bingo, je viens de faire un test sur le caractere recupere, et c'est bien un \n ...
Le truc c'est que je vois pas pourquoi il est encore la ... et comment le virer, vu que le fflush(stdin) n'a pas l'air de fonctionner  
 
edit : bon bah maniere bourrin, deux getchar() enchaines et c'est bon  
par contre, si quelqu'un peut m'indiquer les raisons pour lesquelles je me fais jeter avec un appel a getch(), je suis preneur  

 
Je ne vois pas comment ça peut marcher sur FC2 ce code car la ligne de commande de GCC n'est pas la bonne. Il faut lui indiquer qu'il faut se lier à la lib curses avec le flag -lcurses ( ou -lncurses peut-être )

C'est parce que précédemment, il doit y avoir un scanf() qui a 'oublié' un '\n' dans stdin.
 
http://mapage.noos.fr/emdel/notes.htm#saisie

Je dirais même plus, il reste certainement un '\n' sur l'entrée standard. Je dirais même plus, il reste certainement un '\n' sur l'entrée standard. Je dirais même plus, il reste certainement un '\n' sur l'entrée standard. Je dirais même plus, il reste certainement un '\n' sur l'entrée standard. Je dirais même plus, il reste certainement un '\n' sur l'entrée standard. Je dirais même plus, il reste certainement un '\n' sur l'entrée standard. Je dirais même plus, il reste certainement un '\n' sur l'entrée standard. Je dirais même plus, il reste certainement un '\n' sur l'entrée standard. Je dirais même plus, il reste certainement un '\n' sur l'entrée standard. Je dirais même plus, il reste certainement un '\n' sur l'entrée standard. Je dirais même plus, il reste certainement un '\n' sur l'entrée standard.

Normal, fflush() ne fonctionne que sur les flux sortants.

Ou utiliser d'autres fonctions de saisies... Voir l'article en référence dans mon autre message.

getch() n'est pas standard. Ton compilateur peut l'avoir ou non... Peut être manque-t-il une bibliothèque...

 
Gnie, j'ai mal positionne ma remarque, ce qui fonctionne nickel sous FC2 c'est le code du debut de post ... pour ce qui est du getch je n'ai pas pu le tester sous FC2 (fac) car je suis sous MDK10 (maison)
 
Je corrige tout de suite    
 
Merci pour l'info sur le flag, je testerai ca  
 
edit : fautes d'orthographe corrigees

 
 
En tout cas merci a tous pour vos petites infos ;-)

Si. Corrigé.

C'est à la fonction de saisie de faire le ménage tout de suite après, sans préjuger de ce qui se passe après (ou avant).

Les fonctions de saisies basées sur fgets() font la saisie et le nettoyage d'un coup (dans les cas 'normaux').
 
http://mapage.noos.fr/emdel/clib.htm
Module IO
 
 

Oki, c'est note, merci beaucoup  

Bon, le fgets() resoud tous mes problemes (j'aurais jamais pense avoir des ennuis avec les scanf ... lol), par contre il m'en pose un autre ... il arrete la lecture du flux lorsqu'il trouve EOF ou \n ... mais il place quand meme le \n dans la chaine resultat, ce que je ne veux pas ...
gets() serait parfait mais comme il ne gere pas les depassements de buffer, on oublie ...  
 
Pas moyen de trouver pile poil ce qu'il me faut, va falloir que je code une tite routine pour virer \n de ma chaine  
 
edit : fautes d'orthographe corrigees

c'est normal. alors après un fgets victorieux (~ sans erreur , tu sors ton strchr, et tu cherche l' '\n' et si tu le trouves, tu fous un bon '\0' dessus et ouala

Ouais, mais j'ai fait plus direct, vu que dans ma situation j'ai automatiquement un \n en fin de chaine et que je cherche a le virer systematiquement, je fais ca :

 
Voila    
 
Encore merci a vous tous, et bonne soiree  

Marche pas si le '\n' est absent. Il t'a été recommandé d'utiliser strchr(), ce n'est pas sans raisons :

 
Oui, mais comme je l'ai precise, dans ma situation (i.e. la maniere dont mon programme fonctionne) je me retrouve systematiquement avec un \n comme dernier caractere, donc ce que j'utilise suffit amplement.
Je ne teste pas le dernier caractere pour savoir si c'est \n et le remplacer si c'est le cas, je le remplace de maniere aveugle.
 
Dans l'hypothese (bug de lecture de la ligne) ou \n ne se trouverait pas en derniere position dans la chaine, comme je remplace le dernier caractere avec \0, bah au pire je tronque la chaine d'un caractere (qui serait deja tronquee suite au bug de lecture) ... et comme cette chaine n'est utilisee que pour un simple affichage ulterieur, c'est pas vraiment un drame   (cette chaine n'est pas critique pour le fonctionnement du prog, c'est juste pour une question d'esthetique que je vire \n)
 
Par contre, je suis d'accord avec toi et Taz, dans le cas ou la chaine necessite d'etre traitee de maniere plus rigoureuse, strchr() est necessaire    
 
Sur ce, je m'en retourne a mon gcc    
 
Merci encore  

Avec fgets(), ce n'est pas garanti. Si tu entres une ligne plus longue que le tampon, la ligne saisie sera tronquée et le '\n' absent.
 
C'est tout l'intérêt de fgets() qui est non seulement sûr (tu connais les problèmes de gets()), mais qui en plus permet de gérer finement la saisie. Si le '\n' est absent, on peut décider d'agrandir le tampon et d'acquérir la suite, ou alors de lire les caractères non lus et de les ignorer. Bref, on a la maîtrise de la saisie...

 
Oui, tout a fait d'accord, mais soit je me fais mal comprendre soit tu n'as pas lu la totalite de mon post    ...  
Si le tampon est trop petit, fgets() tronque la ligne (jusque la on est d'accord), mais comme je remplace systematiquement le dernier caractere de la chaine par \0, dans le pire des cas je me retrouve a tronquer d'un caractere supplementaire une chaine deja tronquee a la saisie ... recuperer une chaine tronquee n'est pas un probleme pour moi, tout ce que je veux c'est virer un \n final, c'est pour ca que ma methode me suffit  
 
Voila, je passe le post en resolu, histoire d'eviter de tourner en rond    
 
Bonne journee a tous et bonnes fetes de fin d'annee  

Et tu trouves ça bien ?

Et tu fais quoi des caractères non lus, et notamment du '\n' qui reste dans le flux entrant ?
 
Tu vas retomber dans le problème du scanf() qui ne lit pas le dernier '\n'...
 
Je te propose une méthode universelle qui marche à tout les coups et toi tu te contentes d'une méthode bancale... C'est ton choix... mais je ne le respecte pas...

 
Dans le cas precis de mon programme oui (dans d'autres situations non) car j'utilise des buffers de 256 caracteres et je suis bien loin de les remplir lors d'une saisie clavier (c'est pour ca que j'indiquais que la probabilite de lecture tronquee etait vraiment faible ... je devrais meme dire nulle)
 

 
Rien, il n'y en a pas vu que je ne fais jamais de saisie clavier superieure a 256 caracteres
 

 
Euh, on est pas la pour se taper dessus    
Je ne critique ni ne remets en cause ta methode, je suis d'ailleurs content que tu me l'ai indiquee et je t'en remercie. Mais comme je l'ai deja dit, dans mon cas precis je n'ai pas besoin d'une gestion rigoureuse de la saisie donc ma methode (qui n'est pas bancale dans le contexte de mon programme) me convient tres bien.
 
Oui, dans l'absolu ta methode est vraiment rigoureuse.
J'espere avoir ete assez clair, sinon la prochaine fois je vais etre oblige de poster la totalite de mon code pour me justifier    
 
Bonne soiree a tous  

whiterabbit> j'ai pas beaucoup d'expérience mais je pensse que ta démarche n'est pas très bonne, quand on développe on a pas à imaginer que l'utilisateur fera ça ou ça exactement, on doit faire en sorte de prévenir toutes éventualitées, c'est comme mettre des barrières le long d'une route en bordure de falaise. Sur des petites applis perso ça semble peut-être insignifiant mais sur des applis plus complexe ou qui sortent d'un cadre personnel ça devient problématique.  
 
Puis je pensse que ça fait simplement partie des bonnes habitudes à prendre tout simplement, je pensse qu'en info sans rigueur on va droit vers le mur, pas qu'en info d'ailleur...

Oui, mais la justement je suis dans l'optique d'une petite appli perso, et plus precisement pour du debug, c'est pour ca que je parle du "contexte" de mon programme. Le seul utilisateur ici sera moi, donc je ne m'avance pas trop en disant que je n'ai pas de risque de me retrouver avec une chaine saisie tronquee.
 
Pour ce qui est de la rigueur qui est de mise en info, on est d'accord sur tout la ligne, et moi aussi je suis pour les barrieres le long des routes qui longent les falaises (et meme le long de toutes les routes dans certains cas).
 
Bye