J'ai trouver un moyen pour faire fonctionner un getch() avec des cout<< "cout<<endl;" toujours avant mon getch().
Un flush() devrais suffire, non ?
Ya-t-il une équivalence en c++ du getch() qui serait plus compatible avec le cout ?
Pas que je sache, non. getch() retourne dès l'appuie d'une touche, c'est ça ? Si c'est le cas, alors il faut chercher du côté de ncurses pour avoir quelque chsoe de portable.
-- Arnaud (Supprimez les geneurs pour me répondre)
?ric Mass? wrote:
J'ai trouver un moyen pour faire fonctionner un getch() avec des cout<<
"cout<<endl;" toujours avant mon getch().
Un flush() devrais suffire, non ?
Ya-t-il une équivalence en c++ du getch() qui serait plus compatible avec le cout ?
Pas que je sache, non. getch() retourne dès l'appuie d'une touche, c'est
ça ? Si c'est le cas, alors il faut chercher du côté de ncurses pour
avoir quelque chsoe de portable.
--
Arnaud
(Supprimez les geneurs pour me répondre)
J'ai trouver un moyen pour faire fonctionner un getch() avec des cout<< "cout<<endl;" toujours avant mon getch().
Un flush() devrais suffire, non ?
Ya-t-il une équivalence en c++ du getch() qui serait plus compatible avec le cout ?
Pas que je sache, non. getch() retourne dès l'appuie d'une touche, c'est ça ? Si c'est le cas, alors il faut chercher du côté de ncurses pour avoir quelque chsoe de portable.
-- Arnaud (Supprimez les geneurs pour me répondre)
Horst Kraemer
(?ric Mass?) wrote:
J'ai trouver un moyen pour faire fonctionner un getch() avec des cout<<
"cout<<endl;" toujours avant mon getch().
Qu'est qui ne "fonctionne" pas sans cout<<endl ?
-- Horst
-- Lâche pas la patate!
ericmas001@yahoo.ca (?ric Mass?) wrote:
J'ai trouver un moyen pour faire fonctionner un getch() avec des cout<<
On Thu, 18 Nov 2004 18:14:49 +0100, Horst Kraemer :
Qu'est qui ne "fonctionne" pas sans cout<<endl ?
J'imagine que l'op ne connaissait pas flush()...
-- ;-)
Christophe Lephay
Horst Kraemer wrote:
(?ric Mass?) wrote:
J'ai trouver un moyen pour faire fonctionner un getch() avec des cout<<
"cout<<endl;" toujours avant mon getch().
Qu'est qui ne "fonctionne" pas sans cout<<endl ?
C'est le problème récurrent lorsqu'on utilise les I/O héritées du C avec les flux du C++. C'est un problème de synchronisation des buffers entre les unes et les autres (ce que règle le endl comme le flush).
Chris
Horst Kraemer wrote:
ericmas001@yahoo.ca (?ric Mass?) wrote:
J'ai trouver un moyen pour faire fonctionner un getch() avec des
cout<<
"cout<<endl;" toujours avant mon getch().
Qu'est qui ne "fonctionne" pas sans cout<<endl ?
C'est le problème récurrent lorsqu'on utilise les I/O héritées du C avec les
flux du C++. C'est un problème de synchronisation des buffers entre les unes
et les autres (ce que règle le endl comme le flush).
J'ai trouver un moyen pour faire fonctionner un getch() avec des cout<<
"cout<<endl;" toujours avant mon getch().
Qu'est qui ne "fonctionne" pas sans cout<<endl ?
C'est le problème récurrent lorsqu'on utilise les I/O héritées du C avec les flux du C++. C'est un problème de synchronisation des buffers entre les unes et les autres (ce que règle le endl comme le flush).
Chris
Fabien LE LEZ
On Thu, 18 Nov 2004 19:29:28 +0100, "Christophe Lephay" :
C'est le problème récurrent lorsqu'on utilise les I/O héritées du C avec les flux du C++.
getch() n'a rien à voir avec les I/O du C. Par contre, quand on l'appelle (et donc quand le programme se fige en attendant une touche), tout ce qui a été envoyé sur cout n'est pas forcément présent à l'écran en l'absence de flush().
-- ;-)
On Thu, 18 Nov 2004 19:29:28 +0100, "Christophe Lephay"
<christophe-lephay@wanadoo.fr>:
C'est le problème récurrent lorsqu'on utilise les I/O héritées du C avec les
flux du C++.
getch() n'a rien à voir avec les I/O du C.
Par contre, quand on l'appelle (et donc quand le programme se fige en
attendant une touche), tout ce qui a été envoyé sur cout n'est pas
forcément présent à l'écran en l'absence de flush().
On Thu, 18 Nov 2004 19:29:28 +0100, "Christophe Lephay" :
C'est le problème récurrent lorsqu'on utilise les I/O héritées du C avec les flux du C++.
getch() n'a rien à voir avec les I/O du C. Par contre, quand on l'appelle (et donc quand le programme se fige en attendant une touche), tout ce qui a été envoyé sur cout n'est pas forcément présent à l'écran en l'absence de flush().
-- ;-)
Christophe Lephay
Fabien LE LEZ wrote:
On Thu, 18 Nov 2004 19:29:28 +0100, "Christophe Lephay" :
C'est le problème récurrent lorsqu'on utilise les I/O héritées du C avec les flux du C++.
getch() n'a rien à voir avec les I/O du C. Par contre, quand on l'appelle (et donc quand le programme se fige en attendant une touche), tout ce qui a été envoyé sur cout n'est pas forcément présent à l'écran en l'absence de flush().
Bah, je dirais qu'il en est dans la lignée même s'il ne fait pas partie du C standard. La problématique reste la même.
Chris
Fabien LE LEZ wrote:
On Thu, 18 Nov 2004 19:29:28 +0100, "Christophe Lephay"
<christophe-lephay@wanadoo.fr>:
C'est le problème récurrent lorsqu'on utilise les I/O héritées du C
avec les flux du C++.
getch() n'a rien à voir avec les I/O du C.
Par contre, quand on l'appelle (et donc quand le programme se fige en
attendant une touche), tout ce qui a été envoyé sur cout n'est pas
forcément présent à l'écran en l'absence de flush().
Bah, je dirais qu'il en est dans la lignée même s'il ne fait pas partie du C
standard. La problématique reste la même.
On Thu, 18 Nov 2004 19:29:28 +0100, "Christophe Lephay" :
C'est le problème récurrent lorsqu'on utilise les I/O héritées du C avec les flux du C++.
getch() n'a rien à voir avec les I/O du C. Par contre, quand on l'appelle (et donc quand le programme se fige en attendant une touche), tout ce qui a été envoyé sur cout n'est pas forcément présent à l'écran en l'absence de flush().
Bah, je dirais qu'il en est dans la lignée même s'il ne fait pas partie du C standard. La problématique reste la même.
Chris
Fabien LE LEZ
On Thu, 18 Nov 2004 20:38:30 +0100, "Christophe Lephay" :
Bah, je dirais qu'il en est dans la lignée
Non.
La problématique reste la même.
Pas vraiment. Ce que tu évoques est le manque de synchronisation entre cout et printf, qui a pour résultat d'afficher les informations dans le désordre. Ici, le problème est plus simple : il s'agit du fait que le buffering empêche le programmeur d'être sûr que l'affichage est complet à un point donné de l'exécution du programme (à moins d'appeler flush explicitement). Remplacer "getch" par un "sleep" quelconque, par exemple, ne changerait rien au problème.
-- ;-)
On Thu, 18 Nov 2004 20:38:30 +0100, "Christophe Lephay"
<christophe-lephay@wanadoo.fr>:
Bah, je dirais qu'il en est dans la lignée
Non.
La problématique reste la même.
Pas vraiment. Ce que tu évoques est le manque de synchronisation entre
cout et printf, qui a pour résultat d'afficher les informations dans
le désordre. Ici, le problème est plus simple : il s'agit du fait que
le buffering empêche le programmeur d'être sûr que l'affichage est
complet à un point donné de l'exécution du programme (à moins
d'appeler flush explicitement). Remplacer "getch" par un "sleep"
quelconque, par exemple, ne changerait rien au problème.
On Thu, 18 Nov 2004 20:38:30 +0100, "Christophe Lephay" :
Bah, je dirais qu'il en est dans la lignée
Non.
La problématique reste la même.
Pas vraiment. Ce que tu évoques est le manque de synchronisation entre cout et printf, qui a pour résultat d'afficher les informations dans le désordre. Ici, le problème est plus simple : il s'agit du fait que le buffering empêche le programmeur d'être sûr que l'affichage est complet à un point donné de l'exécution du programme (à moins d'appeler flush explicitement). Remplacer "getch" par un "sleep" quelconque, par exemple, ne changerait rien au problème.
-- ;-)
Christophe Lephay
Fabien LE LEZ wrote:
On Thu, 18 Nov 2004 20:38:30 +0100, "Christophe Lephay" :
Bah, je dirais qu'il en est dans la lignée
Non.
Pour ce que je me rappelle du getch, c'etait en premier lieu une extension des I/O du C standard sur leur compilo Turbo C.
La problématique reste la même.
Pas vraiment. Ce que tu évoques est le manque de synchronisation entre cout et printf, qui a pour résultat d'afficher les informations dans le désordre. Ici, le problème est plus simple : il s'agit du fait que le buffering empêche le programmeur d'être sûr que l'affichage est complet à un point donné de l'exécution du programme (à moins d'appeler flush explicitement). Remplacer "getch" par un "sleep" quelconque, par exemple, ne changerait rien au problème.
Ben "le manque de synchronisation entre cout et printf" et "le buffering qui empeche d'etre sur que l'affichage est complet", c'est pas un peu la même chose ?
Chris
Fabien LE LEZ wrote:
On Thu, 18 Nov 2004 20:38:30 +0100, "Christophe Lephay"
<christophe-lephay@wanadoo.fr>:
Bah, je dirais qu'il en est dans la lignée
Non.
Pour ce que je me rappelle du getch, c'etait en premier lieu une extension
des I/O du C standard sur leur compilo Turbo C.
La problématique reste la même.
Pas vraiment. Ce que tu évoques est le manque de synchronisation entre
cout et printf, qui a pour résultat d'afficher les informations dans
le désordre. Ici, le problème est plus simple : il s'agit du fait que
le buffering empêche le programmeur d'être sûr que l'affichage est
complet à un point donné de l'exécution du programme (à moins
d'appeler flush explicitement). Remplacer "getch" par un "sleep"
quelconque, par exemple, ne changerait rien au problème.
Ben "le manque de synchronisation entre cout et printf" et "le buffering qui
empeche d'etre sur que l'affichage est complet", c'est pas un peu la même
chose ?
On Thu, 18 Nov 2004 20:38:30 +0100, "Christophe Lephay" :
Bah, je dirais qu'il en est dans la lignée
Non.
Pour ce que je me rappelle du getch, c'etait en premier lieu une extension des I/O du C standard sur leur compilo Turbo C.
La problématique reste la même.
Pas vraiment. Ce que tu évoques est le manque de synchronisation entre cout et printf, qui a pour résultat d'afficher les informations dans le désordre. Ici, le problème est plus simple : il s'agit du fait que le buffering empêche le programmeur d'être sûr que l'affichage est complet à un point donné de l'exécution du programme (à moins d'appeler flush explicitement). Remplacer "getch" par un "sleep" quelconque, par exemple, ne changerait rien au problème.
Ben "le manque de synchronisation entre cout et printf" et "le buffering qui empeche d'etre sur que l'affichage est complet", c'est pas un peu la même chose ?
Chris
drkm
"Christophe Lephay" writes:
Ben "le manque de synchronisation entre cout et printf" et "le buffering qui empeche d'etre sur que l'affichage est complet"
"... avant une entrée".
c'est pas un peu la même chose ?
Non. Mais ça a avoir dans les deux cas avec le buffering des sorties.
Ben "le manque de synchronisation entre cout et printf" et "le buffering qui empeche d'etre sur que l'affichage est complet"
"... avant une entrée".
c'est pas un peu la même chose ?
Non. Mais ça a avoir dans les deux cas avec le buffering des sorties.
--drkm
Jean-Marc Bourguet
drkm writes:
"Christophe Lephay" writes:
Ben "le manque de synchronisation entre cout et printf" et "le buffering qui empeche d'etre sur que l'affichage est complet"
Je rappelle l'existante en C++ de std::ios_base::sync_with_std_io() qui retourne true au premier appel (autrement dit il ne devrait pas y avoir de problèmes de synchronisation entre les cin et stdin d'une part cout, cerr, clog et stdout, stderr de l'autre.
"... avant une entrée".
c'est pas un peu la même chose ?
Non. Mais ça a avoir dans les deux cas avec le buffering des sorties.
De même cin est "tied" avec cout, ce qui fait que les demande d'entrées sur cin vide le tampon de cout (et stdout si on n'a pas utilisé sync_with_std_io).
Il n'y a pas une telle synchronisation pour stdin avec stdout, mais par contre stdout est souvent bufferisé par ligne quand il est connecté à un terminal, ce qui n'existe pas en C++.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Ben "le manque de synchronisation entre cout et printf"
et "le buffering qui empeche d'etre sur que l'affichage
est complet"
Je rappelle l'existante en C++ de
std::ios_base::sync_with_std_io()
qui retourne true au premier appel (autrement dit il ne
devrait pas y avoir de problèmes de synchronisation entre
les cin et stdin d'une part cout, cerr, clog et stdout,
stderr de l'autre.
"... avant une entrée".
c'est pas un peu la même chose ?
Non. Mais ça a avoir dans les deux cas avec le buffering des
sorties.
De même cin est "tied" avec cout, ce qui fait que les
demande d'entrées sur cin vide le tampon de cout (et stdout
si on n'a pas utilisé sync_with_std_io).
Il n'y a pas une telle synchronisation pour stdin avec
stdout, mais par contre stdout est souvent bufferisé par
ligne quand il est connecté à un terminal, ce qui n'existe
pas en C++.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Ben "le manque de synchronisation entre cout et printf" et "le buffering qui empeche d'etre sur que l'affichage est complet"
Je rappelle l'existante en C++ de std::ios_base::sync_with_std_io() qui retourne true au premier appel (autrement dit il ne devrait pas y avoir de problèmes de synchronisation entre les cin et stdin d'une part cout, cerr, clog et stdout, stderr de l'autre.
"... avant une entrée".
c'est pas un peu la même chose ?
Non. Mais ça a avoir dans les deux cas avec le buffering des sorties.
De même cin est "tied" avec cout, ce qui fait que les demande d'entrées sur cin vide le tampon de cout (et stdout si on n'a pas utilisé sync_with_std_io).
Il n'y a pas une telle synchronisation pour stdin avec stdout, mais par contre stdout est souvent bufferisé par ligne quand il est connecté à un terminal, ce qui n'existe pas en C++.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
