Hallo,
da es den Befehl "fflush(stdin);" in Linux ja nicht gibt bzw. er keine
Auswirkung hat suche ich jetzt eine Möglichkeit den Eingabepuffer zu
leeren um mit scanf/getchar dann einzelne Zeichen bzw. Strings sauber
einlesen kann.
Momentan arbeite ich mit
1
while(getchar()!='\n')
Allerdings muss ich dann zweimal Enter drücken. Bei Windows mit der
fflush-Funktion brauche ich beim gleichen Code nur ein Enter.
Gibt es eine einfachere/bessere Möglichkeit den Eingabepuffer komplett
zu leeren??
MFG Mixer
Klaus Wachtler schrieb:
> Was hast du vor?> Für etwas ähnliches wie ein Konsolenprogramm mit Menüsteuerung ist> die Standardeingabe eher ungeeignet.
Sowas habe ich aber vor. Was soll ich dann stattdessen nehmen??
fflush() ist ISO C90. Warum sollte es diese Funktion ausgerechnet unter
Linux nicht geben? fflush() schreibt alle _Ausgabe-Daten und duerfte
deshalb keinen Effekt auf stdin haben.
Was du suchst ist fpurge(), das ist aber keine Standard-Funktion. Wenn
es standard-konform sein muss, dann wuerde ich mir mit fileno() den
filedescriptor holen und dann mit read() alle Daten lesen.
Um abzubrechen wenn keine daten mehr im File sind, wurder ich entweder
select() nehmen oder den fd non-blocking setzen.
Ansonsten koenntest du eine Funktion von ncurses verwenden(?)
Meine Lösung für solche Fälle ist _getch(). _kbhit() (conio.h
mit diesen Funktionen gibt es auch unter DOS/Windows); weil man
es für Quelltexte aus der Windowswelt öfter braucht, ist Sleep()
auch gleich mit dabei, auch wenn es dort nicht zu conio.h gehört.
Wer es also etwas eleganter will, wirft Sleep() hier raus und
packt sie in die richtige Headerdatei.
_kbhit() liefert true, wenn ein Zeichen geholt werden kann, ohne
zu blockieren.
_getch() liefert ein Zeichen, oder im Fehlerfall -1.
_putch() gibt ein Zeichen aus.
Sleep() wartet die angegebene Zahl msec.
Eine Headerdatei conio.h:
Wieso wollen alle eigentlich immer fflush dafür mißbrauchen? fflush
dient dazu, den Inhalt des Puffers an sein Ziel zu schreiben (und nicht
etwa zu verwerfen, wie viele zu glauben scheinen) , was natürlich nur
für Ausgangspuffer einen Sinn ergibt.
Deswegen hat es ja bei stdin auch keinen Sinn. So wie ich das verstanden
habe.
Hatte aber letztens das Problem, dass ich perror vor einem printf
aufgerufen hab und der Text von perror stand NACH dem von printf. Da
half nur ein fflush(stdout).
Verstehe aber selber nicht so genau warum das in dem Fall verdreht wird.
Wusste nur, dass man solche Phänomenen damit entgegnen kann.
> Deswegen hat es ja bei stdin auch keinen Sinn. So wie ich das verstanden> habe.
Richtig.
> Hatte aber letztens das Problem, dass ich perror vor einem printf> aufgerufen hab und der Text von perror stand NACH dem von printf.
War's nicht anders herum? Eigentlich sollte perror (stderr) ungepuffert
direkt ans Terminal raus, während stdout puffert und der Text daher
evtl. erst später ankommt.
War eine Schleife, also ist quasi vor dem perror auch nach dem perror.
Kann also sein, dass es auch mit den printfs davor zusammenhing. :-)
Aber warum ist perror nicht der Einfachheit halber auch gepuffert? Ist
doch blöd wenn man sich da noch als Anwender einer API um
Puffersynchronisierung kümmern muss.
Simon K. schrieb:
> War eine Schleife, also ist quasi vor dem perror auch nach dem perror.> Kann also sein, dass es auch mit den printfs davor zusammenhing. :-)> Aber warum ist perror nicht der Einfachheit halber auch gepuffert?
Weil es erlaubt ist, dass eine normale Ausgabe durchaus auch eine halbe
Stunde im Ausgabebuffer steht.
Bei einer Fehlermeldung ist es aber unter Umständen mehr als fatal, wenn
sie durch das I/O System verzögert wird.
Karl heinz Buchegger schrieb:
> Simon K. schrieb:>> War eine Schleife, also ist quasi vor dem perror auch nach dem perror.>> Kann also sein, dass es auch mit den printfs davor zusammenhing. :-)>> Aber warum ist perror nicht der Einfachheit halber auch gepuffert?>> Weil es erlaubt ist, dass eine normale Ausgabe durchaus auch eine halbe> Stunde im Ausgabebuffer steht.> Bei einer Fehlermeldung ist es aber unter Umständen mehr als fatal, wenn> sie durch das I/O System verzögert wird.
Halbe Stunde? Ich dachte der Sinn von dem Puffer in dem Fall ist, dass
immer gesammelt wird und spätestens alle X Millisekunden das als ein
Haufen an das System übermittelt wird um den Aufruf Overhead zu
verringern. Bzw das Verhältnis von Daten zu Overhead zur erhöhen.
Simon K. schrieb:
> Halbe Stunde? Ich dachte der Sinn von dem Puffer in dem Fall ist, dass> immer gesammelt wird und spätestens alle X Millisekunden das als ein> Haufen an das System übermittelt wird
Wie soll das auf einem Nicht-Multitasking System gehen?
Üblich ist, dass der Buffer bei einem bestimmten Füllgrad bzw beim
Auftreten eines \n geleert wird (oder durch einen fflush)
Wenn ich 2 Zeichen (ohne \n) in den Buffer stelle und dann eine halbe
Stunde keinen printf mache, dann können die beiden Zeichen durchaus eine
halbe Stunde im Ausgabebuffer warten, bis ich sie dann endlich mit einem
\n erlöse.
> Aber warum ist perror nicht der Einfachheit halber auch gepuffert?
Es ist nicht speziell perror, sondern generell alles, was nach stderr
geht. Das wird deshalb gemacht, weil dahin oft eben Debug- oder
Fehlerausgaben geschrieben werden, bevor ein Programm abschmiert, und
dann will man, daß diese Ausgaben auch sicher ankommen und nicht
irgendwo im Puffer versickern, denn der verschwindet zusammen mit dem
Programm.