Scanfs blockieren sich gegenseitig

Also bleibt alles in allem nur

while((c = getchar()) != '\n' && c != EOF){}

oder das verhasste

fflsuh(stdin)

übrig für den Anfänger?

SeppJ

kenner der c streams schrieb:

nix mit puffer? lol! klar mit puffer. weil der stream gepuffert ist, also werden die sich im puffer befindenden zeichen eingelesen.

Und wenn da nix ist? Oder mehr als du denkst? Hier kann ich schon aufhören, denn der Rest deines Arguments beruht ja auf der Fehlannahme, dass das irgendeinen Unterschied machen würde. Jedoch macht es keinen, wie du leicht an Testprogrammen feststellen kannst.

DirkB schrieb:

Du gehst in deinem Beispiel doch von einer fehlerhaften Eingabe aus.

kenner der c streams schrieb:

... wenn z.b. 123abc eingegeben wurde...

richtig!

DirkB schrieb:

Und wenn da zweimal (oder noch öfter) die Entertaste gedrückt wurde, stehen diese '\n' noch im Eingabestrom.

tun sie nicht.
nach dem ersten drücken der entertaste ist scanf fertig. das programm fährt fort und es wird die schleife ausgeführt, welche die falscheingabe verwirft.
es wird also nur der erste druck der enter-taste berücksichtigt.

SeppJ schrieb:

Und wenn da nix ist?

hatte ich schon geschrieben.
wenn da nichts ist, wird auf eine eingabe gewartet.
hättst du selbst lesen können, aber bitte, für dich extra noch einmal:

kenner der c streams schrieb:

diese funktion mit der schleife ist aber keine eierlegende wollmilchsau!
bedenke: beim aufruf dieser funktion wird auf eine eingabe gewartet, wenn sich
kein zeichen im puffer befinden!

SeppJ schrieb:

Oder mehr als du denkst?

hatte ich auch schon geschrieben, als antwort auf deinen vorigen beitrag.
das such bitte selbst, ich zitiere mich nicht noch einmal selbst.

SeppJ

beginner88888 schrieb:

Also bleibt alles in allem nur
while((c = getchar()) != '\n' && c != EOF){}
oder das verhasste
fflsuh(stdin)
übrig für den Anfänger?

Kommt drauf an, wofür. Beide machen ganz was unterschiedliches. Das Erste (vom Standard gedeckt) macht, wie es DirkB so schön ausdrückt:

Die Funktion clear_streambuffer macht nicht was der Name suggeriert.
Das ist eher ein discard_to_endofline

Wohingegen das Zweite (nicht vom Standard gedeckte Erweiterung von Microsoft) tatsächlich auf diesem internen Puffer arbeitet, von dem der Unregistrierte Nutzer hier meint, man könne da drauf zugreifen. Dies ist tatsächlich solch eine Möglichkeit, aber das ist ja auch kein standardkonformes C.

beginner88888 schrieb:

Also bleibt alles in allem nur
while((c = getchar()) != '\n' && c != EOF){}

genau das ist meine empfehlung.

beginner88888 schrieb:

oder das verhasste
fflsuh(stdin)
übrig für den Anfänger?

das hat laut standard undefiniertes verhalten, funktioniert aber bei diversen os(compilerbedingt) wie z.b. windows.

SeppJ schrieb:

von dem der Unregistrierte Nutzer hier meint, man könne da drauf zugreifen.

ja, das kann man.
die standardfunktionen getchar, scanf, etc. können das. sie greifen darauf zu und lesen daraus ein.

SeppJ

kenner der c streams schrieb:

DirkB schrieb:

Und wenn da zweimal (oder noch öfter) die Entertaste gedrückt wurde, stehen diese '\n' noch im Eingabestrom.

tun sie nicht.
nach dem ersten drücken der entertaste ist scanf fertig. das programm fährt fort und es wird die schleife ausgeführt, welche die falscheingabe verwirft.
es wird also nur der erste druck der enter-taste berücksichtigt.

Sachlich falsch. Kannst du an Testprogrammen prüfen. Diskussion zu Ende?

diese funktion mit der schleife ist aber keine eierlegende wollmilchsau!
bedenke: beim aufruf dieser funktion wird auf eine eingabe gewartet, wenn sich
kein zeichen im puffer befinden!

Soso. Also wohl doch keine Pufferleerung, sondern eine ganz normale Eingabefunktion?

hatte ich auch schon geschrieben, als antwort auf deinen vorigen beitrag.

Bloß war das "siehst du, darum wirst du in einem gepufferten stream keine zwei oder mehr newlines auf einmal vorfinden. " schlicht falsch. Also wohl doch nix mit Puffern.

Da ich mir ziemlich sicher bin, dass du der gleiche bist, der das Thema vor ein paar Wochen schon einmal diskutiert hat, spare ich mir mal die Gegenbeweisprogramme und weitere Argumente. Da du BEWEISE damals schon ignoriert hast, ist dir nicht zu helfen oder es ist absichtliche Trollerei. Falls du interessiert bist, ist das auch leicht selber zu testen.

@all: Falls den Typ irgendjemand ernst nimmt: Bitte melden. Dann konstruiere ich ein Gegenbeispiel.

SeppJ schrieb:

@all: Falls den Spinner irgendjemand ernst nimmt: Bitte melden. Dann konstruiere ich ein Gegenbeispiel.

ach, jetzt werden wir auch noch beleidigend?
immer schön sachlich bleiben, es sei denn du bist scharf darauf dir selbst armutszeugnisse auzustellen.
in dem fall darfst du gern so weiter machen

"beweise" ?!
du meinst also dieses "gegenbeispiel":
http://ideone.com/oEMEPG
zeile 7 liest und verwirft das erste newline, zeile 8 liest und verwirft das zweite newline.
in zeile 10 und 11 wird in einer schleife genau das ausgegeben, was eingegeben wird. es wird zeichen für zeichen in den puffer geschrieben und sofort aus dem puffer gelesen und angezeigt. normales programmverhalten.
wo ist das jetzt ein gegenbeispiel?

Da braucht es kein anderes Programm, sondern nur eine andere Eingabe.

Und nach einem Druck auf die Enter-Taste, so wie die Aufforderung in dem Programm ist, ist das Programm nicht zu Ende.
Da muss man mindestens noch eine beliebige Taste und Enter drücken.

DirkB schrieb:

Da braucht es kein anderes Programm, sondern nur eine andere Eingabe.

Und nach einem Druck auf die Enter-Taste, so wie die Aufforderung in dem Programm ist, ist das Programm nicht zu Ende.
Da muss man mindestens noch eine beliebige Taste und Enter drücken.

selbstverständlich ist das programm nicht zu ende!
warum sollte das auch zu ende sein?!
das ist doch nicht mein beispiel!
hab ich doch auch schon längst geschrieben, das die besagte schleife auf eine eingabe wartet, wenn nix im eingabestrom ist!