while schleife nicht ausführbar
-
@Wade1234 Daß ein Compiler (bzw. dessen Implementierung der Standardbibliothek) von dem bisher in diesem Thread nichteinmal die Rede war für fflush() auf Inputstreams etwas tut, das der Großteil der restlichen Welt anders sieht, ist nicht wirklich ein gutes Argument.
-
@Wade1234 sagte in while schleife nicht ausführbar:
also der visual c++ compiler kann fflush(stdin) verarbeiten, steht ganz klar im msdn.
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fflush?view=vs-2017Das ist eine MS-Spezialität.
fflush on input stream is an extension to the C standard
Bei MS geht auch das:
for (int i = 0; i < count; i++) { // Mach was .. } printf ("%d\n", i); // i ist hier gültig!
-
-
@Swordfish sagte in while schleife nicht ausführbar:
@RBS2 sagte in while schleife nicht ausführbar:
Bei MS geht auch das:
In welchem Jahr?
Das war bei Visual Studio 2015 noch so.
MS versteht das wohl als Feature, nicht als Bug.
-
@Swordfish sagte in while schleife nicht ausführbar:
In welchem Jahr?
Siehe dazu auch:
Die /Zc: forScope Option ist standardmäßig aktiviert.
-
Von deinem Link im Original:
Standard behavior is to let a for loop's initializer go out of scope after the for loop. Under /Zc:forScope- [off] and /Ze, the for loop's initializer remains in scope until the local scope ends.
The /Zc:forScope option is on by default.
Diese Passage in der Doku ist für 2015 und 2017 genau gleich. Also hat 2015 das mit den Standardeinstellungen sicher nicht erlaubt. Zumal /Zc:forScope- schon in 2015 deprecated war.
gcc
hat bis 2.7 dasselbe gemacht um alten pre-Standard-Code nicht zu brechen.
-
@Swordfish sagte in while schleife nicht ausführbar:
@Wade1234 Daß ein Compiler (bzw. dessen Implementierung der Standardbibliothek) von dem bisher in diesem Thread nichteinmal die Rede war für fflush() auf Inputstreams etwas tut, das der Großteil der restlichen Welt anders sieht, ist nicht wirklich ein gutes Argument.
ein wirklich gutes argument wäre halt, die bedienungsanleitung des compilers zu lesen. und: diese funktion wurde doch ganz oben verwendet und halt an einer bestimmten stelle vergessen, oder irre ich da?
-
@Wade1234 sagte in while schleife nicht ausführbar:
diese funktion wurde doch ganz oben verwendet und halt an einer bestimmten stelle vergessen, oder irre ich da?
Ich hab' doch nirgends gesagt, daß der op
fflush(stdin)
nicht verwendet hat. Nur, wenn es Visual Studio wäre, dann täte das Programm genau das, was man erwartet. Passt also nicht zur Beschreibung des OPs. Unter POSIX dagegen hatfflush(stdin)
keinen Effekt.
-
@Swordfish sagte in while schleife nicht ausführbar:
gcc hat bis 2.7 dasselbe gemacht um alten pre-Standard-Code nicht zu brechen.
Vermutlich um Code nicht zu brechen, der für den MS-Compiler gedacht ist.
Aber das fflush(stdin)-Feature wollten die GCC-Macher wohl doch nicht mehr nachbauen.
-
@RBS2 sagte in while schleife nicht ausführbar:
Vermutlich um Code nicht zu brechen, der für den MS-Compiler gedacht ist.
Witzkeks. Vor C++98 war es (von C übernommen) so, daß die Schleifenvariable im das
for
-Statement enthaltenden Scope gültig war.@RBS2 sagte in while schleife nicht ausführbar:
Aber das fflush(stdin)-Feature wollten die GCC-Macher wohl doch nicht mehr nachbauen.
Das ist keine Entscheidung der
gcc
-Typen sondern vom POSIX-Standard. Und es wäre auch ziemlich bescheuert wenn ein Compiler der hauptsächlich auf POSIX-Systemen davon abweichen würde.
-
@Swordfish sagte in while schleife nicht ausführbar:
Vor C++98 war es (von C übernommen) so, daß die Schleifenvariable im das for-Statement enthaltenden Scope gültig war.
Dass man die Schleifenvariable im Kopf einer for-Schleife anlegen kann, war vor C99 auch noch nicht möglich. Da hat sich etwas C++ in unser schönes C eingeschlichen. Denn so richtig viel bringt das ja nicht, aber sieht eben schicker aus.
-
@Swordfish
nein eben nicht. probiers doch aus, da fehlt nämlich ein fflush
-
@Wade1234 Wo und warum soll das fehlen?
@RBS2 ich meinte damit die Notwendigkeit, in C vor C99{ int i; // ... for( i=0; i <42; ++) // ... // ... }
schreiben zu müssen.
-
nein das war auf das fflush bezogen. das fehlt an einer stelle (und wird nebenbei vor dem einlesen aufgerufen und nicht danach) und deshalb läuft die whileschleife nicht vernünftig.
-
"an einer Stelle" ja ... wo? Bei mir (msvc) läuft es wie es soll.
-
naja nach der eingabe für den zweiten wert von y wird das ergebnis gar nicht mehr angezeigt bzw. das programm beendet sich unmittelbar nach drücken der entertaste.
-
fflush(stdin) ist trotzdem irgendwie schräg.
'Flush' bedeutet ja: "Pufferinhalt jetzt sofort schreiben",
was fflush ja sonst auch macht. Aber ein 'fflush(stdin)' bedeutet: "Pufferinhalt verwerfen".
-
@Wade1234 sagte in while schleife nicht ausführbar:
naja nach der eingabe für den zweiten wert von y wird das ergebnis gar nicht mehr angezeigt bzw. das programm beendet sich unmittelbar nach drücken der entertaste.
Das Ergebnis wird sehr wohl angezeigt
@Lambodiablogt sagte in while schleife nicht ausführbar:
printf("\nErgebnis:%i",erg);
und bei mir (wie gesagt
msvc
- sonst machtfflush(stdin)
sowieso keinen Sinn) garted dasgetch()
(bzw._getch()
) wieder. (Ja, ich weiß, eigentlich sollte mindestens noch ein newline instdin
sein, aber es funktioniert mitmsvc
zumindest trotzdem.) Das einzige was fehlt ist die neuerliche ausgabe des Promptsprintf("Wollen Sie noch ein wert berechnrn drücken sie j");
und ein paar newlines für die Lesbarkeit.
-
ja aber die schleife wird bei mir nur einmal durchlaufen bzw. das while könnte man auch durch ein if ersetzen. oder ist mein rechner zu schnell und das drücken von enter beim 2. y wird auch noch von getch ausgewertet?
-
@Wade1234 sagte in while schleife nicht ausführbar:
bei mir
Compiler?
@Wade1234 sagte in while schleife nicht ausführbar:
oder ist mein rechner zu schnell und das drücken von enter beim 2. y wird auch noch von getch ausgewertet?
Ich hab' doch oben geschrieben, daß (zumindest meiner Logik nach) das newline vom zweiten
scanf()
in der Schleife noch instdin
sein und daraufhin vongetch()
gelesen werden sollte. Warum es (msvc 19
) nicht so ist ... ich weiß es nicht.