Eternel problème : comment faire pour faire une pause dans un programme?
Je dois afficher un message d'erreur à l'utilisateur, puis qu'il
appuie sur entrer pour repasser sur le menu principal.
Sous Linux, ça marche comme partout ailleurs, mais il faut voir ce que tu as fais avant. Il se peut qu'il y a une erreur avant qui ne se manifeste qu'ici, ou que tu n'as pas pensé à lire toute la ligne avant, ce qui fait q'il y a encore une (partie de) ligne dans le buffer. Et évidemment, si tu utilises quelque chose du genre curses, qui a changé le mode des entrées clavier, ça risque de ne pas marcher non plus.
Dans ce cas, je ne comprends pas pourquoi ça ne marche pas. Je ne touche pas au ncurses. Tout ce que je fais, c'est afficher un message avant.
Es-tu sûr de ce qui se trouve dans ton flux d'entrée ?
--drkm
Pascal <teapa5@B022-05.fr> writes:
On Thu, 10 Feb 2005 01:13:39 -0800, kanz wrote:
Sous Linux, ça marche comme partout ailleurs, mais il faut voir
ce que tu as fais avant. Il se peut qu'il y a une erreur avant
qui ne se manifeste qu'ici, ou que tu n'as pas pensé à lire
toute la ligne avant, ce qui fait q'il y a encore une (partie
de) ligne dans le buffer. Et évidemment, si tu utilises quelque
chose du genre curses, qui a changé le mode des entrées clavier,
ça risque de ne pas marcher non plus.
Dans ce cas, je ne comprends pas pourquoi ça ne marche pas. Je ne touche pas au ncurses. Tout ce que
je fais, c'est afficher un message avant.
Es-tu sûr de ce qui se trouve dans ton flux d'entrée ?
Sous Linux, ça marche comme partout ailleurs, mais il faut voir ce que tu as fais avant. Il se peut qu'il y a une erreur avant qui ne se manifeste qu'ici, ou que tu n'as pas pensé à lire toute la ligne avant, ce qui fait q'il y a encore une (partie de) ligne dans le buffer. Et évidemment, si tu utilises quelque chose du genre curses, qui a changé le mode des entrées clavier, ça risque de ne pas marcher non plus.
Dans ce cas, je ne comprends pas pourquoi ça ne marche pas. Je ne touche pas au ncurses. Tout ce que je fais, c'est afficher un message avant.
Es-tu sûr de ce qui se trouve dans ton flux d'entrée ?
--drkm
Pascal
drkm wrote:
Es-tu sûr de ce qui se trouve dans ton flux d'entrée ?
A part avoir fait cout << "machin", y a rien d'autre. Peut être parce que je mets 2 "n", mais dans ce cas, le fflush(NULL) aurait dû tout supprimer. -- Pascal
drkm wrote:
Es-tu sûr de ce qui se trouve dans ton flux d'entrée ?
A part avoir fait cout << "machin", y a rien d'autre. Peut être parce
que je mets 2 "n", mais dans ce cas, le fflush(NULL) aurait dû tout
supprimer.
--
Pascal
Es-tu sûr de ce qui se trouve dans ton flux d'entrée ?
A part avoir fait cout << "machin", y a rien d'autre. Peut être parce que je mets 2 "n", mais dans ce cas, le fflush(NULL) aurait dû tout supprimer. -- Pascal
kanze
Pascal wrote:
drkm wrote:
Es-tu sûr de ce qui se trouve dans ton flux d'entrée ?
A part avoir fait cout << "machin", y a rien d'autre. Peut être parce que je mets 2 "n", mais dans ce cas, le fflush(NULL) aurait dû tout supprimer.
Je ne suis pas sûr de comprendre. Tu sembles mélanger les entrées et les sorties.
Il s'agit ici des entrées. Donc, le « cout << ... » et le « fflush » n'ont aucun effet -- ils ne sont définis que sur des flux de sortie (et évidemment, fflush n'a aucun effet sur les flux C++ en général).
La question est plutôt : est-ce que tu as fais des entrées avant, et comment ? Si tu as fais des entrées partielles, il est possible, voire probable, qu'il te reste une partie de la ligne lue avant dans le buffer de cin. Dans ce cas-là, getline retourne tout de suite avec cette reste de ligne.
En général (mais ce n'est qu'un avis personnel), je le trouve mieux d'éviter de mélanger les types d'entrées. Si les entrées sont orientées ligne (ce qui est normalement le cas pour cin), on lit au moyen de getline, et uniquement au moyen de getline. Pour découper et analyser plus finement, on se sert de istringstream. Il y a des exceptions, mais dans le cas d'exception, il faut quand même bien avancer jusqu'à la fin de ligne quand on a fini.
Enfin, un peu à part : quel est l'intérêt de cette procedure ? Les seuls cas que je connais où on veut se bloquait jusqu'une entrée utilisateur, ce sont les outils du genre more ou pg, et typiquement, ils gèrent les entrées d'une façon spéciale afin d'offir des possibilités en plus. (Je crois, par exemple, que le less de GNU utilise getline.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Pascal wrote:
drkm wrote:
Es-tu sûr de ce qui se trouve dans ton flux d'entrée ?
A part avoir fait cout << "machin", y a rien d'autre. Peut
être parce que je mets 2 "n", mais dans ce cas, le
fflush(NULL) aurait dû tout supprimer.
Je ne suis pas sûr de comprendre. Tu sembles mélanger les
entrées et les sorties.
Il s'agit ici des entrées. Donc, le « cout << ... » et le
« fflush » n'ont aucun effet -- ils ne sont définis que sur des
flux de sortie (et évidemment, fflush n'a aucun effet sur les
flux C++ en général).
La question est plutôt : est-ce que tu as fais des entrées
avant, et comment ? Si tu as fais des entrées partielles, il est
possible, voire probable, qu'il te reste une partie de la ligne
lue avant dans le buffer de cin. Dans ce cas-là, getline
retourne tout de suite avec cette reste de ligne.
En général (mais ce n'est qu'un avis personnel), je le trouve
mieux d'éviter de mélanger les types d'entrées. Si les entrées
sont orientées ligne (ce qui est normalement le cas pour cin),
on lit au moyen de getline, et uniquement au moyen de getline.
Pour découper et analyser plus finement, on se sert de
istringstream. Il y a des exceptions, mais dans le cas
d'exception, il faut quand même bien avancer jusqu'à la fin de
ligne quand on a fini.
Enfin, un peu à part : quel est l'intérêt de cette procedure ?
Les seuls cas que je connais où on veut se bloquait jusqu'une
entrée utilisateur, ce sont les outils du genre more ou pg, et
typiquement, ils gèrent les entrées d'une façon spéciale afin
d'offir des possibilités en plus. (Je crois, par exemple, que le
less de GNU utilise getline.)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Es-tu sûr de ce qui se trouve dans ton flux d'entrée ?
A part avoir fait cout << "machin", y a rien d'autre. Peut être parce que je mets 2 "n", mais dans ce cas, le fflush(NULL) aurait dû tout supprimer.
Je ne suis pas sûr de comprendre. Tu sembles mélanger les entrées et les sorties.
Il s'agit ici des entrées. Donc, le « cout << ... » et le « fflush » n'ont aucun effet -- ils ne sont définis que sur des flux de sortie (et évidemment, fflush n'a aucun effet sur les flux C++ en général).
La question est plutôt : est-ce que tu as fais des entrées avant, et comment ? Si tu as fais des entrées partielles, il est possible, voire probable, qu'il te reste une partie de la ligne lue avant dans le buffer de cin. Dans ce cas-là, getline retourne tout de suite avec cette reste de ligne.
En général (mais ce n'est qu'un avis personnel), je le trouve mieux d'éviter de mélanger les types d'entrées. Si les entrées sont orientées ligne (ce qui est normalement le cas pour cin), on lit au moyen de getline, et uniquement au moyen de getline. Pour découper et analyser plus finement, on se sert de istringstream. Il y a des exceptions, mais dans le cas d'exception, il faut quand même bien avancer jusqu'à la fin de ligne quand on a fini.
Enfin, un peu à part : quel est l'intérêt de cette procedure ? Les seuls cas que je connais où on veut se bloquait jusqu'une entrée utilisateur, ce sont les outils du genre more ou pg, et typiquement, ils gèrent les entrées d'une façon spéciale afin d'offir des possibilités en plus. (Je crois, par exemple, que le less de GNU utilise getline.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze
Alexandre wrote:
"Pascal" a écrit dans le message de news:
On Tue, 08 Feb 2005 22:51:18 +0100, Fabien LE LEZ wrote:
string ligne_bidon; getline (cin, ligne_bidon);
sous linux, ca ne marche pas. Alors j'ai pensé à faire un fflush(null), mais ça n'a pas marché.
si tu veux vider le buffer d'entrée je ferais plutôt cin.sync() ; avant.
Fonctionne qui n'existe pas.
-- James Kanze home: www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Alexandre wrote:
"Pascal" <teapa5@B022-05.fr> a écrit dans le message de news:
pan.2005.02.09.14.24.50.409495@B022-05.fr...
On Tue, 08 Feb 2005 22:51:18 +0100, Fabien LE LEZ wrote:
string ligne_bidon;
getline (cin, ligne_bidon);
sous linux, ca ne marche pas. Alors j'ai pensé à faire un
fflush(null), mais ça n'a pas marché.
si tu veux vider le buffer d'entrée je ferais plutôt
cin.sync() ;
avant.
Fonctionne qui n'existe pas.
--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
On Tue, 08 Feb 2005 22:51:18 +0100, Fabien LE LEZ wrote:
string ligne_bidon; getline (cin, ligne_bidon);
sous linux, ca ne marche pas. Alors j'ai pensé à faire un fflush(null), mais ça n'a pas marché.
si tu veux vider le buffer d'entrée je ferais plutôt cin.sync() ; avant.
Fonctionne qui n'existe pas.
-- James Kanze home: www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
