Guten Tag,
habe diese Schleife in einer älteren C-Firmware von Pic-Microchip
gesehen
und gerätselt:
for(;;)
{
if ((SWITCH_S2) && (!Flags.MotorRunning))
{
while(SWITCH_S2);
RunMotor(); // Run motor if push button is pressed and motor is
// stopped
}
else if ((SWITCH_S2) && (Flags.MotorRunning))
{
while(SWITCH_S2);
StopMotor();// Stop motor if push button is pressed and motor is
// running
}
}
Hat jemand schon eine solch eigenartige for-Schleife gesehen?
Helmut -. schrieb:> Jan S. schrieb:>> Hat jemand schon eine solch eigenartige for-Schleife gesehen?>> Ja. Endlosschleife.
Danke für die Antwort, da hätte man doch gleich while(1) schreiben
können, hat mich etwas verwirrt...
Gruss Jan
Danke auch @ Joachim, Gruss Jan
Jan S. schrieb:> Danke für die Antwort, da hätte man doch gleich while(1) schreiben> können, hat mich etwas verwirrt...
for(;;) kann man als "forever" lesen, das finde ich schöner als
while(1). Da kann man immer noch befürchten, dass es doch mal aufhört ;)
edit: Bonus: for(;;) spart 1 Zeichen!
Bauform B. schrieb:> Jan S. schrieb:>> Danke für die Antwort, da hätte man doch gleich while(1) schreiben>> können, hat mich etwas verwirrt...>> for(;;) kann man als "forever" lesen, das finde ich schöner als> while(1). Da kann man immer noch befürchten, dass es doch mal aufhört ;)
edit: Bonus: for(;;) spart 1 Zeichen!
☺️☺️ Gruss Jan
Jan S. schrieb:> da hätte man doch gleich while(1) schreiben können
Bei "for (;;)" ist offensichtlich, dass der Autor das so wollte, das
entsteht nicht mal irgendwo aus Versehen.
"while(1)" könnte beispielsweise aus einer Makroersetzung "while
(IS_SOMETHING_GOING_ON())" kommen, deren Inhalt unbeabsichtigt zu "1"
wurde, daher lässt man sowas den Compiler lieber warnen.
Folglich gibt es style guides, die "for (;;)" explizit für eine
Endlosschleife vorschreiben.
Hallo,
Jan S. schrieb:> ...da hätte man doch gleich while(1) schreiben> können...
Im Buch "Code complete" von Steve McConnell wird für C empfohlen eine
Endlosschleife mit einem Makro einzuleiten:
@Jörg
@Roland
@Wilhelm
Danke für die Antworten.
Ach, als wäre es nicht schon kompliziert genug, sich durch all die
Deklarationen und Makros von Microchip zu kämpfen...
😓 Gruss Jan
Jörg W. schrieb:> "while(1)" könnte beispielsweise aus einer Makroersetzung "while> (IS_SOMETHING_GOING_ON())" kommen, deren Inhalt unbeabsichtigt zu "1"> wurde, daher lässt man sowas den Compiler lieber warnen.
Was soll der Compiler denn warnen, wenn das Macro zu 1 oder true ersetzt
wird?
Wilhelm M. schrieb:> Was soll der Compiler denn warnen, wenn das Macro zu 1 oder true ersetzt> wird?
"condition is always true" oder sowas.
Zumindest irgendwelche lint müssen sowas moniert haben.
Bauform B. schrieb:> Jan S. schrieb:>> Danke für die Antwort, da hätte man doch gleich while(1) schreiben>> können, hat mich etwas verwirrt...>> for(;;) kann man als "forever" lesen, das finde ich schöner als
Lächerlich.
Hinterlass lieber einen comment, der auch dem dümmsten Source-Code Leser
klar macht, was hier gemeint ist.
Und wer sich nicht scheut, das "verpönte" goto in C einzusetzen könnte
es auch schreiben wie es realisiert wird:
forever: goto forever;
https://www.javatpoint.com/infinite-loop-in-chttps://stackoverflow.com/questions/20186809/endless-loop-in-c-c
for(;;) ist vorgesehen als Standard-Endlosschleife.
While erfordert einen Ausdruck, während bei "for" das zweite Argument
explizit optional ist (die andern beiden auch, da braucht es aber keine
Sonderbehandlung):
"An omitted expression-2 is replaced by a nonzero constant"
Frank M. schrieb:> Auf den ersten Blick ein schöner Hack, allerdings wird
1
while("never")
2
{
3
}
> leider nicht den gewünschten Effekt haben.
War auch nicht die Intention. Jedes Stringarray steht an einer Adresse
!= 0. Der Inhalt des Strings ist also immer egal.
Wilhelm M. schrieb:> Roland F. schrieb:>> Im Buch "Code complete" von Steve McConnell wird für C empfohlen eine>> Endlosschleife mit einem Makro einzuleiten:>>>>
Bruno V. schrieb:> for(;;) ist vorgesehen als Standard-Endlosschleife.> While erfordert einen Ausdruck, während bei "for" das zweite Argument> explizit optional ist
Ja, das ist für mich auch der Grund, warum ich for(;;) bevorzuge. Es
gibt keine Bedingung für die Schleife, und bei for kann ich das auch
direkt so ausdrücken. Bei while muss ich dagegen eine Pseudo-Bedingung
hinschreiben.
Rolf M. schrieb:> Bruno V. schrieb:>> for(;;) ist vorgesehen als Standard-Endlosschleife.>> While erfordert einen Ausdruck, während bei "for" das zweite Argument>> explizit optional ist>> Ja, das ist für mich auch der Grund, warum ich for(;;) bevorzuge. Es> gibt keine Bedingung für die Schleife, und bei for kann ich das auch> direkt so ausdrücken.
Das ist doch an den Haaren herbei geholt!
> Bei while muss ich dagegen eine Pseudo-Bedingung> hinschreiben.
Wieso Pseudo? Die Bedingung statt ganz klar als Literal "true" dort. Nix
Pseudo.
Bei for steht nichts, und man muss, falls man das Idiom nicht kennt,
nachdenken. Bei while steht es explizit da. Und explizit ist immer
besser als implizit.
Peter D. schrieb:> int main(void)> {> do> {> // ...> }> while("Forever");> }
"while forever" ("während für immer") sagt kein Mensch, nicht einmal ein
Engländer aus gehobenen Kreisen. Deswegen etwas besser:
1
for(;"ever";){
2
...
3
}
Aber wie die meisten Vorposter würde ich des "ever" einfach weglassen :)
Wilhelm M. schrieb:>> Ja, das ist für mich auch der Grund, warum ich for(;;) bevorzuge. Es>> gibt keine Bedingung für die Schleife, und bei for kann ich das auch>> direkt so ausdrücken.>> Das ist doch an den Haaren herbei geholt!
Warum? Ich will eine unbedingte Schleife, habe also keine Bedingung. Bei
for kann ich diese weglassen und bekomme dann genau das, was ich will.
Was ist daran "an den Haaren herbei geholt"? Das passt doch nun wirklich
wie die sprichwörtliche Faust aufs Auge.
Wilhelm M. schrieb:>> Bei while muss ich dagegen eine Pseudo-Bedingung>> hinschreiben.>> Wieso Pseudo?
Weil eine 1 von nichts abhängt. Damit ist es keine echte Bedingung. In
Assembler würde ich eine Endlosschleife auch nicht so schreiben, dass
ich in jedem Durchlauf prüfe, ob 1 immer noch ungleich 0 ist und dann
einen bedingten Sprung machen. In C(++) muss ich das auch nicht, dank
for(;;).
> Bei for steht nichts, und man muss, falls man das Idiom nicht kennt,> nachdenken.
Ja, wenn man ein Sprachelement nicht kennt, muss man "nachdenken", bzw.
es eben lernen.
> Bei while steht es explizit da.
Was? Da steht ein "true". Also eine Schleife, die so lange läuft, wie
"wahr" wahr ist. Das ist nicht explizit in der Aussage, dass ich eine
unbedingte Schleife haben will. Es ist unnötig umständlich.
Ich versuche eigentlich immer, möglichst das hinzuschreiben, was ich
meine. So schreibe ich z.B. wenn ich einen Integer mit 2 multiplizieren
will, * 2 hin und nicht << 1. Und wenn ich eine Schleife ohne Bedingung
will, schreibe ich eben eine ohne Bedingung hin und nicht eine mit einer
"Bedingung", die auf triviale Weise immer true ist.
> Und explizit ist immer besser als implizit.
Richtig.
Gegen while(1) spricht, dass manche statischen Analyse-Tools meckern,
wenn man sie nicht entsprechend konfiguriert. Üblicher ist
wahrscheinlich while(1), weil es "lesbarer" ist. Auch wenn for(;;) wohl
eher die bestimmungsgemäße Variante für eine Endlosschleife ist.
Aber um sich ein FOREVER-Macro zu machen muss man ja völlig besoffen
sein...
Rolf M. schrieb:> Weil eine 1 von nichts abhängt. Damit ist es keine echte Bedingung.
Natürlich gibt es Bedingungen, die immer wahr sind.
> In> Assembler würde ich eine Endlosschleife auch nicht so schreiben,
Dann mach das doch auch in C.
Rolf M. schrieb:> Was? Da steht ein "true".
Sehr richtig.
> Also eine Schleife, die so lange läuft, wie> "wahr" wahr ist. Das ist nicht explizit in der Aussage, dass ich eine> unbedingte Schleife haben will.
Sehr explizit.
Denn wo ist es denn explizit bei /for(;;)/, dass es eine endlos Schleife
sein soll??? Das muss man sich mühsam, aus dem C-Standard raussuchen.
> Es ist unnötig umständlich.> Ich versuche eigentlich immer, möglichst das hinzuschreiben, was ich> meine. So schreibe ich z.B. wenn ich einen Integer mit 2 multiplizieren> will, * 2 hin und nicht << 1. Und wenn ich eine Schleife ohne Bedingung> will, schreibe ich eben eine ohne Bedingung hin und nicht eine mit einer> "Bedingung", die auf triviale Weise immer true ist.
Und dieser Satz stört Dich bei /for(;;)/ nicht?
"An omitted expression-2 is replaced by a nonzero constant"
Der Bedingungsausdruck ist nämlich auch bei for konstant, und damit
keine Bedingung nach Deiner Definition.
Wilhelm M. schrieb:>> In>> Assembler würde ich eine Endlosschleife auch nicht so schreiben,>> Dann mach das doch auch in C.
Hä? Das mache ich doch. Das war doch genau der Punkt. Dazu brauche ich
aber for, weil das mit while nicht geht.
> Rolf M. schrieb:>> Was? Da steht ein "true".>> Sehr richtig.>>> Also eine Schleife, die so lange läuft, wie>> "wahr" wahr ist. Das ist nicht explizit in der Aussage, dass ich eine>> unbedingte Schleife haben will.>> Sehr explizit.
Also ich finde "Schleife: …" eher explizit für eine Endlosschleife als
"Schleife, solange wahr wahr ist: …".
> Denn wo ist es denn explizit bei /for(;;)/, dass es eine endlos Schleife> sein soll???
Es ist sehr explizit darin, dass es eine Schleife ist, die keine
Bedingung hat, also eine Endlosschleife, denn es steht ja keine
Bedingung dran, von der die weitere Ausführung abhängen könnte.
> Das muss man sich mühsam, aus dem C-Standard raussuchen.
Und da sprichst du von an den Haaren herbeigezogenen Dingen. Ich habe
schon ganz zu Anfang gelernt, dass bei for() alle drei Teile optional
sind. Das sollte eigentlich in jedem Anfängerbuch stehen.
> Und dieser Satz stört Dich bei /for(;;)/ nicht?>> "An omitted expression-2 is replaced by a nonzero constant"
Nö, warum? Wie der Compiler das umsetzt, ist mir eigentlich egal.
Rolf M. schrieb:> Es ist sehr explizit darin...
Ersetze explizit mit kryptisch, dann passt es.
Oder in deiner Sprache: 's/explizit/kryptisch/'
Rolf M. schrieb:> So schreibe ich z.B. wenn ich einen Integer mit 2 multiplizieren> will, * 2 hin und nicht << 1.
Sehr löblich. Warum Du dann bei Schleifen Konstrukte bevorzugst, die
aussehen als wenn eine Katze über die Tastatur gelaufen ist, weißt wohl
nur du.
Joe schrieb:> Ein Blick in das C-Standardwerk K&R 'Programmieren in C' zeigt> diese Form der Endlosschleife als die von den Autoren bevorzugte.> for(;;)
Damit habe ich vor 35 Jahren C gelernt, und selbst da war das Buch schon
10 Jahre alt.
Wenn man das als Dogma nehmen möchte, macht man sicher nix falsch.
Ich bin trotzdem froh, dass sich die Welt seither etwas weitergedreht
hat.
Wilhelm M. schrieb:> Das muss man sich mühsam, aus dem C-Standard raussuchen.Klaus schrieb:> Ersetze explizit mit kryptisch, dann passt es.
Ich muss sagen, dass ich doch erstaunt bin, dass so erfahrene
Programmierer derart große Probleme mit so einem simplen Konzept haben.
Rolf M. schrieb:> Wilhelm M. schrieb:>> Das muss man sich mühsam, aus dem C-Standard raussuchen.>> Ich muss sagen, dass ich doch erstaunt bin, dass so erfahrene> Programmierer derart große Probleme mit so einem simplen Konzept haben.
Du weißt schon noch, wer die Frage gestellt hat, oder?
Klaus schrieb:> Joe schrieb:>> Ein Blick in das C-Standardwerk K&R 'Programmieren in C' zeigt>> diese Form der Endlosschleife als die von den Autoren bevorzugte.>> for(;;)>> Damit habe ich vor 35 Jahren C gelernt, und selbst da war das Buch schon> 10 Jahre alt.
In der 10 Jahre jüngeren 2. Auflage steht das immer noch so :)
> Wenn man das als Dogma nehmen möchte, macht man sicher nix falsch.> Ich bin trotzdem froh, dass sich die Welt seither etwas weitergedreht> hat.
Natürlich hat sich seither vieles verändert, aber wohl kaum die
Argumentation für oder gegen for bzw. while zur Bildung von
Endlosschleifen.
Chuck Norris würde übrigens while nehmen, aber nicht etwa while(1),
sondern
1
while(UINTMAX_MAX){
2
...
3
}
Das ergibt nämlich nicht nur unendlich viele, sondern UINTMAX_MAX mal
unendlich viele Schleifendurchläufe, so dass er mehr Spaß beim Abzählen
derselben hat. Wenn er damit durch ist, ändert er UINTMAX_MAX in
INFINITY ;-)
> Natürlich hat sich seither vieles verändert, aber wohl kaum die> Argumentation für oder gegen for bzw. while zur Bildung von> Endlosschleifen .
Doch, da hat sich gerade im Embedded einiges getan, sogar bis zur
Abschaffung der Schleife als Realisierung eines (Endlosen) Dauerlauf.
Und zwar durch Implementierung verschiedener Sleep-Modus und diverse
Möglichkeiten des Aufwachens.
Aber das nur für die (Embedded-)Entwickler, die gewillt sind, über den
Tellerand einer Akademischen Instrumentalisierung einer
Programmiersprache hinaus zu schauen ;-)
BTW: weitaus wichtiger für einen Programmierer als der
(absichtliche/unabsichtliche) Start in eine Endlos-Schleife sind die
Möglichkeiten eine solche kontrolliert zu verlassen, gerade weil eben
das Ende in einer Endlos-Schleife nicht vorgesehen ist ;-)
Rudolph R. schrieb:> Ansonsten hat aber Jörg da ganz weit oben das schon gut begründet,
Hört sich fast so an, als wärt ihr katholisch: nur weil das vor Äonen
schon mal im K&R stand, bedeutet das (für mich) nicht, dass man das so
machen sollte. Ich denke da lieber selbst ;-)
> hier> noch ein Link dazu als Beispiel für Coding Guidelines:> https://barrgroup.com/embedded-systems/books/embedded-c-coding-standard/statement-rules/for-while-loops
Dort steht auch gar keine Begründung, sondern nur eine Kodier-Anweisung.
Das Beispiel ist ja völlig irrelevant (s.a. Fußnote dort), weil man eben
heute auch C nicht while(1) sondern while(true) schreibt (schreiben
sollte).
Klaus schrieb:> Joe schrieb:>> Ein Blick in das C-Standardwerk K&R 'Programmieren in C' zeigt>> diese Form der Endlosschleife als die von den Autoren bevorzugte.>> for(;;)>> Damit habe ich vor 35 Jahren C gelernt, und selbst da war das Buch schon> 10 Jahre alt.> Wenn man das als Dogma nehmen möchte, macht man sicher nix falsch.> Ich bin trotzdem froh, dass sich die Welt seither etwas weitergedreht> hat.
Mir ging es nur um die Frage des TO ob schon mal jemand for(;;) gesehen
hat.
Ich selber schreibe auch lieber while(1). Letztlich ist es einfach
Geschmackssache. Jeder wie er's mag.
DSGV-Violator schrieb:> Doch, da hat sich gerade im Embedded einiges getan, sogar bis zur> Abschaffung der Schleife als Realisierung eines (Endlosen) Dauerlauf.> Und zwar durch Implementierung verschiedener Sleep-Modus und diverse> Möglichkeiten des Aufwachens.
So, wie ich das bei den Pic-MC verstanden habe, muss zwingend eine
Endlosschlaufe vorhanden sein od. bei ASM loop: goto od. branch to loop.
Sonst würde der Programmzähler ins Leere laufen oder?
DSGV-Violator schrieb:> Doch, da hat sich gerade im Embedded einiges getan, sogar bis zur> Abschaffung der Schleife als Realisierung eines (Endlosen) Dauerlauf.> Und zwar durch Implementierung verschiedener Sleep-Modus und diverse> Möglichkeiten des Aufwachens.
Was hat das eine jetzt mit dem anderen zu tun?
Ohne Software-Schleife kommt man nur aus wenn das Programm immer wieder
durch den Reset-Vector läuft, ansonsten schickt man den Controller am
Ende der Schleife in den gewünschten Sleep-Mode und ist durch das
Wakeup-Event am Anfang der Schleife.
In einen PowerDown Mode zu gehen ist eher sowas wie das Programm zu
beenden um irgendwann später mal neu zu starten, aber doch nicht was für
den regulären Umlauf, dafür dauert das Aufwachen viel zu lange.
Wilhelm M. schrieb:> Grundsätzlich sind in C/C++ Endlos-Schleifen, die keine Seiteneffekte> enthalten, UB
Sie können entfernt werden, ja. Aber, dass sie UB sind, würde ich mal
stark bezweifeln. Wo steht das?
MaWin O. schrieb:> Wilhelm M. schrieb:>> Grundsätzlich sind in C/C++ Endlos-Schleifen, die keine Seiteneffekte>> enthalten, UB>> Sie können entfernt werden, ja. Aber, dass sie UB sind, würde ich mal> stark bezweifeln. Wo steht das?
1
In a valid C++ program, every thread eventually does one of the following:
2
3
terminate;
4
makes a call to an I/O library function;
5
performs an access through a volatile glvalue;
6
performs an atomic operation or a synchronization operation.
7
This allows the compilers to remove all loops that have no observable behavior, without having to prove that they would eventually terminate because it can assume that no thread of execution can execute forever without performing any of these observable behaviors.
Das bedeutet, dass eine Endlos-Schleife ohne Seiteneffekt kein valides
C++ Programm ist. Und das bedeutet, dass es UB ist.
Wilhelm M. schrieb:>> hier>> noch ein Link dazu als Beispiel für Coding Guidelines:>>> https://barrgroup.com/embedded-systems/books/embedded-c-coding-standard/statement-rules/for-while-loops>> Dort steht auch gar keine Begründung, sondern nur eine Kodier-Anweisung.>> Das Beispiel ist ja völlig irrelevant (s.a. Fußnote dort), weil man eben> heute auch C nicht while(1) sondern while(true) schreibt (schreiben> sollte).
Die Fußnote hast Du also gefunden, da steht auch eine Begründung.
Mit while(true) bin ich nicht einverstanden, aber der Grund für meinen
Post war auch nicht das for(;;) zu verteidigen oder was anderes
abzulehnen, sondern eine konkrete Coding Guideline zu zitieren in
welcher das genau so gefordert ist.
"8.4.c. Infinite loops shall be implemented via controlling expression
for (;;)."
Wenn man sich an eine Coding Guideline halten muss, dann gibt es da gar
keine Diskussion mehr, die Fußnote macht es nur leichter von der
persönlichen Vorliebe abzuweichen um am Ende Regel-konformen Code
abzuliefern.
Hast Du schon mal einen Pull-Request in einem größeren Projekt gemacht?
Wilhelm M. schrieb:> In a valid C++ program, every thread eventually does one of the> following:
Aus welcher Version ist das? Im letzten Draft, den ich finden konnte,
fängt dieser Absatz mit "The implementation may assume that any thread
will eventually do one of the following:" an.
Wilhelm M. schrieb:> In a valid C++ program, every thread eventually does one of the> following:
Und was startet die Threads?
Doch nicht etwa der Scheduler der in einer Endlos-Schleife läuft?
Rudolph R. schrieb:> Doch nicht etwa der Scheduler der in einer Endlos-Schleife läuft?
Erstens ist durch den Standard nicht vorgegeben, wie der Scheduler
implementiert sein muss, zweitens wüsste ich nicht, wie er ohne "side
effects" in der Lage sein soll, Threads zu starten.
Rolf M. schrieb:> Rudolph R. schrieb:>> Doch nicht etwa der Scheduler der in einer Endlos-Schleife läuft?>> Erstens ist durch den Standard nicht vorgegeben, wie der Scheduler> implementiert sein muss, zweitens wüsste ich nicht, wie er ohne "side> effects" in der Lage sein soll, Threads zu starten.
Das ist auch nicht relevant dafür das jedes Embedded Programm irgendwo
eine Endlos-Schleife haben muss und der Versuch den Goalpost auf Threads
zu verschieben eher albern war in dem Zusammenhang.
Rudolph R. schrieb:> Das ist auch nicht relevant dafür das jedes Embedded Programm irgendwo> eine Endlos-Schleife haben muss
Lies dir den Standard-Text halt einfach mal genau durch. Es ist sehr
genau definiert (kein UB) wann eine Endlosschleife wegoptimiert werden
kann. Eine Embedded-Endlossschleife fällt dort in der Regel nicht
darunter. Es sei denn, sie macht nichts nach außen hin sichtbares.
MaWin O. schrieb:> Lies dir den Standard-Text halt einfach mal genau durch.
"In a valid C++ program, every *thread*"
"The implementation may assume that any *thread*"
Alles nach thread ist doch in dem Kontext hier bedeutungslos.
Rudolph R. schrieb:> Alles nach thread ist doch in dem Kontext hier bedeutungslos.
Nein, denn wenn es keinen Thread gibt, gibt's auch kein Programm, denn
auch main() und alles, was von da aufgerufen wird, ist Teil eines
Threads. Der Unterschied zu anderen Threads ist lediglich, dass er halt
gleich vom System angelegt wird und nicht manuell erzeugt werden
muss/kann.
> Was hat das eine jetzt mit dem anderen zu tun?
beides ist eine Implementierung von reaktionsbereiten Dauerlauf.
> Ohne Software-Schleife kommt man nur aus wenn das Programm immer wieder> durch den Reset-Vector läuft,
Och, zum Verlassen eine Endlosrn Schleifen gibt es noch weitere
Möglichkeiten wie break oder goto.
> ansonsten schickt man den Controller am> Ende der Schleife in den gewünschten Sleep-Mode und ist durch das> Wakeup-Event am Anfang der Schleife.
Nö, da ist man am Startvector des jeweiligen WakeUps, der nicht gleich
mit dem Start der Schleife sein muß. IRQ ist da beliebt, beim MC68k gabs
da die Unterscheidung in Cold und Cool Capture.
> In einen PowerDown Mode zu gehen ist eher sowas wie das Programm zu> beenden um irgendwann später mal neu zu starten, aber doch nicht was für> den regulären Umlauf, dafür dauert das Aufwachen viel zu lange.
Nö, nicht im Embedded insbesonders beim Batteriebetrieb. Da ist Sleep
der an häufigsten angenommen Betriebszustand. Sleep- und PowerDown ist
nicht unbedingt dasselbe.
DSGV-Violator schrieb:>> Ohne Software-Schleife kommt man nur aus wenn das Programm immer wieder>> durch den Reset-Vector läuft,>> Och, zum Verlassen eine Endlosrn Schleifen gibt es noch weitere> Möglichkeiten wie break oder goto.
Kann es sein, dass du dich verlesen hast?
Eines kann man jedenfalls dem Thread entnehmmen:
Jede Programmiersprache eignet sich bestens zur geistigen Onanie und zur
ausführlichen Diskussion über die resultierenden Ergüsse.
Grad mal im Parser in der Backus.Nauer-Form nachgeschaut.
1
<iteration-statement> ::= while ( <expression> ) <statement>
2
| do <statement> while ( <expression> ) ;
3
| for ( {<expression>}? ; {<expression>}? ; {<expression>}? ) <statement>
Da stellt sich jetzt die Frage ob einauf seinen Start rückgeppolter
Block eine "Iteration" ist und ob es einen Unterschied zwische Iteration
(lat. 'itero') und Repitation (lat.: 'repeto') geben muß.
Rudolph R. schrieb:> Wenn man sich an eine Coding Guideline halten muss, dann gibt es da gar> keine Diskussion mehr,
Leider vollkommen am Thema hier vorbei: es geht um keine
Kodier-Richtinie.
DSGV-Violator schrieb:> Da stellt sich jetzt die Frage ob einauf seinen Start rückgeppolter> Block eine "Iteration" ist und ob es einen Unterschied zwische Iteration> (lat. 'itero') und Repitation (lat.: 'repeto') geben muß.
Warum sollte die Frage, welches lateinische Wort das am besten passende
wäre, für die Diskussion relevant sein?
Roland F. schrieb:> Hallo,>> Leider vollkommen am Thema hier vorbei: es geht um keine>> Kodier-Richtinie.>> Genau, und es geht auch nicht um UB in C++.
Schau nochmal auf welchen Beitrag ich das geschrieben hatte. Und wenn du
magst streiche das ++.
Rolf M. schrieb:> DSGV-Violator schrieb:>> Da stellt sich jetzt die Frage ob einauf seinen Start rückgeppolter>> Block eine "Iteration" ist und ob es einen Unterschied zwische Iteration>> (lat. 'itero') und Repitation (lat.: 'repeto') geben muß.>> Warum sollte die Frage, welches lateinische Wort das am besten passende> wäre, für die Diskussion relevant sein?
Weil eben eine Iteration wie aus dem Mathematischen Prinzip der
vollständigen Induktion bekannt keine Wiederholung (im Kreis laufen)
ist. Kennzeichnen für eine Iteration (fortschreitend, i.e. Spirale) ist
eben der sich ändernde Index, der eben bei der Notation als leere loop
fehlt, obwohl essential für eine Iteration.
https://de.wikipedia.org/wiki/Spirale#Ebene_Spiralenhttps://de.wikipedia.org/wiki/Kreis
Iteration und Repetition sind verwandt, aber linguistisch nicht gleich:
mit Repetition ist die Wiederholung einer Sache in immer derselben Art
gemeint. Mit Iteration ist eine Wiederholung gemeint, die sich von den
vorherigen unterscheidet.
In Bezug auf eine Zustandsmaschine wie ein valides C-Programm (auf einem
µC) dürfte es demnach keine wirkliche Repetition gegen. Denn: ein
C-Programm ohne Seiteneffekte ist kein valides C-Programm, und damit
ändert sich also der Gesamtzustand des Programms (SW und HW). Also haben
wir eine Iteration. Viele Linguisten würden allerdings wohl auch den
Begriff der Repetition als Oberbegriff bezeichnen, und die Iteration ist
dann eben eine spezielle Ausprägung dessen.
Oder man benutzt statt der Fremdwörter "Iteration" und "Repetition"
einfach das deutsche Wort "Schleife" und geht damit automatisch allen
Spitzfindigkeiten aus dem Weg :)
Yalu X. schrieb:> Oder man benutzt statt der Fremdwörter "Iteration" und "Repetition"> einfach das deutsche Wort "Schleife"
Schleife macht man am Schuh.
> und geht damit automatisch allen> Spitzfindigkeiten aus dem Weg :)
Was Du meinst, ist einfache eine Wiederholung.
DSGV-Violator schrieb:> Da stellt sich jetzt die Frage ob einauf seinen Start rückgeppolter> Block eine "Iteration" ist und ob es einen Unterschied zwische Iteration> (lat. 'itero') und Repitation (lat.: 'repeto') geben muß.
Man sollte also vorsichtshalber weder while(true) noch for(;;)
verwenden, sondern sich auf das linguistisch völlig unverdächtige goto
verlegen. ;-)
(prx) A. K. schrieb:> sondern sich auf das linguistisch völlig unverdächtige goto> verlegen. ;-)
Wie soll denn eine CPU oder ein Compiler ganz ohne Füße irgendwo
hingehen?
Hallo,
Yalu X. schrieb:> Oder man benutzt statt der Fremdwörter "Iteration" und "Repetition"> einfach das deutsche Wort "Schleife" und geht damit automatisch allen> Spitzfindigkeiten aus dem Weg :)
Zu einfach, das würde ja jeder verstehen.
rhf
Hallo,
2 Zitate:
Bjarne Stroustrup
"Die etwas eigenartige anmutende Notation for(;;) codiert eine
Endloschleife. Eine alternative Anweisung hierfür ist while(true)."
Ulrich Breymann
Äquivalenz von for und while.
"Eine for Schleife entspricht direkt einer while-Schleife, sie ist im
Grunde nur eine Umformulierung, solange nicht continue vorkommt."
Das heißt, ob nun for(;;) oder while(1) ist vollkommen egal. Die Wirkung
was es tut ist exakt gleich. Von daher schreibt was euch gefällt. Sonst
wird das ein Endlos-Thread. ;-)
Veit D. schrieb:> Das heißt, ob nun for(;;) oder while(1) ist vollkommen egal.
Im originalen C&R hat "for(;;)" gegen "while(1)" deshalb gewonnen,
weil's ein Zeichen weniger zu tippsen ist :-)
Veit D. schrieb:> Das heißt, ob nun for(;;) oder while(1) ist vollkommen egal.
Das wussten wir (ok, vllt außer dem TO) doch schon alle vorher.
> Die Wirkung> was es tut ist exakt gleich.
Auch das ist nichts Neues, und darum ging es ja mal wieder überhaupt
nicht: es ging doch darum, was "besser lesbar" sei. Und das ist nunmal
subjektiv.
> Von daher schreibt was euch gefällt.
Natürlich, was denn sonst?
Johann L. schrieb:> Im originalen C&R hat "for(;;)" gegen "while(1)" deshalb gewonnen,> weil's ein Zeichen weniger zu tippsen ist :-)
Dann sieht's für while(true) ja ganz schlecht aus. 😉
Johann L. schrieb:> Veit D. schrieb:>> Das heißt, ob nun for(;;) oder while(1) ist vollkommen egal.>> Im originalen C&R hat "for(;;)" gegen "while(1)" deshalb gewonnen,> weil's ein Zeichen weniger zu tippsen ist :-)
Wann hat denn der gute Brian seinen Namen gewechselt?
Eine interessante Frage kam mir an diesem sonntaglichen herumlungern:
Gibt es eine Möglichkeit das Abbrechen einer Endlosschleife (Egal ob als
do/while/for...) mittels "break" zu verhindern?
Ich hatte mal den Fall dass ein überzeugter C-Preprozessor Jünger ein
"break" gut in den Innereien versteckt hatte... (Dauerte einige Zeit den
Fehler zu identifizieren. Danach wurde der Hacker mit reichlich
Katzenscheiße beworfen...)
Wilhelm hatte oben doch ein C++ Vorschlag mit
Klaus H. schrieb:> Wilhelm hatte oben doch ein C++ Vorschlag mit> repeat<forever>([]{> // ...> });>> Gibt es da ein Konstrukt?
Was meinst Du?
Wie das obige repeat- realisiert werden soll? Ist eigentlich Grundkurs
generische Programmierung.
Oder, ob es durch ein break abgebrochen werden kann? Nein, kann es
nicht.
Wilhelm M. schrieb:> Wie das obige repeat- realisiert werden soll? Ist eigentlich Grundkurs> generische Programmierung.
Bisher hab ich nur endliche Schleifen erzeugt. Wie würde man eine
endlose Schleife erzeugen?
Klaus H. schrieb:> Bisher hab ich nur endliche Schleifen erzeugt. Wie würde man eine> endlose Schleife erzeugen?
Kannst Du die beiden wesentlichen Elemente benennen, die ich in dem
Beispiel benutzt habe? Dann weißt Du auch die Lösung ;-)
Yalu X. schrieb:> Oder man benutzt statt der Fremdwörter "Iteration" und "Repetition"> einfach das deutsche Wort "Schleife" und geht damit automatisch allen> Spitzfindigkeiten aus dem Weg :)
Wer die Spitzfindigkeit nicht ehrt, ist die C-Syntax nicht wert ;-)
Siehe auch:
https://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest#Flight_simulator
Abgesehen davon das mit einem nur grob ausgebildeten Gefühl für die
Schriftsprache aus dem schmückenden "Schleife knüpfen/binden" schnell
ein strangulierendes "Schlinge knüpfen/binden" wird.
Schlinge, Schleife ... alles nur Gestricke ;-)
Wilhelm M. schrieb:> Kannst Du die beiden wesentlichen Elemente benennen, die ich in dem> Beispiel benutzt habe? Dann weißt Du auch die Lösung ;-)
Was meinst Du? Du nutzt ein Template und als Parameter eine Lambda
Expression.
Klaus H. schrieb:> Was meinst Du? Du nutzt ein Template und als Parameter eine Lambda> Expression.
Perfekt.
Damit sollte doch die Realisierung klar sein, oder?
Wilhelm M. schrieb:> Perfekt.> Damit sollte doch die Realisierung klar sein, oder?
Tatsächlich stehe ich auf dem Schlauch. Es muss ja zur Compilezeit
aufgelöst werden können. Das geht IMHO nur wenn ich im Template eine
Endlosschleife ala while(1) {...} nutze, oder? Dann hab ich aber ja
ursprüngliche Konstrukt.
Wie würdest Du es lösen?
Klaus H. schrieb:> Gibt es da ein Konstrukt?
Damit wird break zu continue, und es ist für jeden was dabei:
for(;;) while(true) {
...
}
Für C-Ästheten:
#define loop for(;;)
#define forever while(true)
loop forever {
...
}
Klaus H. schrieb:> Tatsächlich stehe ich auf dem Schlauch. Es muss ja zur Compilezeit> aufgelöst werden können. Das geht IMHO nur wenn ich im Template eine> Endlosschleife ala while(1) {...} nutze, oder?
Genau.
Da aber das "break" im Closure stehen würde, wäre es syntaktisch falsch.
> Dann hab ich aber ja> ursprüngliche Konstrukt.
Naja, in dem Funktionstemplate kannst Du dann alles benutzen, was wir
hier diskutiert haben, auch Dein goto ;-)
Klaus H. schrieb:> Wilhelm M. schrieb:>> Damit sollte doch die Realisierung klar sein, oder?>> OK, du meinst vermutlich ein Konstrukt ala>>
1
>template<typenameT>voidforever(Tlambda){
2
>while(true){
3
>lambda();
4
>}
5
>}
6
>
7
>intmain(){
8
>forever([](){
9
>//...
10
>});
11
>return0;
12
>}
13
>
Ich hatte verschiedene Spezialisierungen in meinem Beispiel benutzt,
damit kann man es noch etwas ausgestalten.
Oder einfach:
1
voidforever(autof){
2
while(true){
3
f();
4
}
5
}
Was Du übergeben bekommst, ist keine Lamba-Expression, sondern das
Ergebnis(!) einer solchen, also ein Closure. Daher ist der Parametername
"lambda" nicht gut. Es ist einfach ein Funktionsobjekt "f", das kann
auch ein Funktor odgl. sein.
Wilhelm M. schrieb:> Daher ist der Parametername> "lambda" nicht gut. Es ist einfach ein Funktionsobjekt "f", das kann> auch ein Funktor odgl. sein.
Stimmt, die allgemeine Form ist besser.
Danke, dann hatte ich es korrekt verstanden.
Das Konstrukt könnte durchaus mal interessant sein,
wenn viel über Lambda Expressions abgehandelt wird.
Klaus H. schrieb:> Das Konstrukt könnte durchaus mal interessant sein,> wenn viel über Lambda Expressions abgehandelt wird.
Wer generische Lambda-Expressions verstanden hat, der hat C++ verstanden
;-)
Wilhelm M. schrieb:> Wer generische Lambda-Expressions verstanden hat, der hat C++ verstanden> ;-)
Damit hast du keine Probleme, aber dass bei for die Bedingung optional
ist, findest du zu kompliziert?
Rolf M. schrieb:> Wilhelm M. schrieb:>> Wer generische Lambda-Expressions verstanden hat, der hat C++ verstanden>> ;-)>> Damit hast du keine Probleme, aber dass bei for die Bedingung optional> ist, findest du zu kompliziert?
Hallo???
Es ging doch um den TO! Du verdrehst hier immer alles ...
Mein Kommentar bezog sich ganz offensichtlich auf Klaus H., der das
verstanden hat.
Wilhelm M. schrieb:> Rolf M. schrieb:>> Wilhelm M. schrieb:>>> Wer generische Lambda-Expressions verstanden hat, der hat C++ verstanden>>> ;-)>>>> Damit hast du keine Probleme, aber dass bei for die Bedingung optional>> ist, findest du zu kompliziert?>> Hallo???> Es ging doch um den TO!
Und nachdem der TO schon mit for(;;) Probleme hatte, glaubst du, dass er
dieses hier
Wilhelm M. schrieb:> repeat<forever>([]{> // ...> });
auf Anhieb versteht und sogar in der Lage ist, die dafür benötigte
Template-Funktion selber zu schreiben? :-)
Yalu X. schrieb:> Wilhelm M. schrieb:>> Rolf M. schrieb:>>> Wilhelm M. schrieb:>>>> Wer generische Lambda-Expressions verstanden hat, der hat C++ verstanden>>>> ;-)>>>>>> Damit hast du keine Probleme, aber dass bei for die Bedingung optional>>> ist, findest du zu kompliziert?>>>> Hallo???>> Es ging doch um den TO!>> Und nachdem der TO schon mit for(;;) Probleme hatte, glaubst du, dass er> dieses hier
Du bist des Lesens scheinbar auch nicht mächtig.
Nachdem schon eine ganze Reihe dämlicher #defines, etc. kam, habe ich
diese "Antwort" in den Ring geworfen. Sie reiht sich also ganz dort ein.
Allerdings hat sie schon Vorteile, wie manche hier bemerkt haben.
Apollo M. schrieb:> Wem muss ich hier um Erlaubnis fragen
Musst du nicht einmal im Akkusativ. :-) Schau einfach mal das
Eingangsposting, es hatte schlicht jemand gefragt, warum man sowas in
anderer Leute Sourcecode finden kann.
Klaus schrieb:> Probier es aus und teile uns deine Erkenntnisse mit.
Ich habe den Code eingegeben und auf Kompilieren geklickt.
Doch dann tat sich plötzlich hinter meinem Sofa ein riesiges Loch auf.
Es schlagen Flammen heraus und in der Ferne, ganz tief drin, höre ich
Schreie.
Das stand so nicht im K&R-Buch!
Ich warte mal ab. Vielleicht löst sich das ja von ganz alleine.
Da ich gestern in einem anderen Zusammenhang etwas Softwarearchäologie
betrieben habe, erinnerte ich mich auch daran, wie ich nach der Lektüre
des K&R (1. Auflage) meine ersten Gehversuche in C unternahm und schon
damals vor der Frage stand, ob ich für Endlosschleifen besser
1
for(;;)
oder
1
while(1)
schreiben sollte.
Neben der Tatsache, dass im K&R for(;;) explizit als mögliche
Schreibweise für Endlosschleifen aufgeführt war, machte ich mir auch
Gedanken darüber, was wohl der Compiler aus den beiden Varianten macht.
Irgendeiner der mir zur Verfügung stehenden Compiler (ich weiß nicht
mehr genau, welcher), nahm das while(1) tatsächlich wörtlich und
erzeugte Code, der zuerst eine 1 in ein Register lud, dieses Register
auf 0 prüfte und abhängig vom Ergebnis aus der Schleife heraussprang.
Bei for(;;) hingegen generierte er einfach den Schleifenrumpf gefolgt
von einem Sprung zum Schleifenanfang.
Bei den heutigen, optimierenden Compilern, muss man sich solche Gedanken
natürlich nicht mehr machen. Da wird sofort (beim GCC sogar mit -O0)
erkannt, dass die Bedingung 1 trivialerweise immer erfüllt ist und sie
deswegen komplett wegoptimiert werden kann.
Trotzdem frage ich mich, warum man für eine Schleife, deren Rumpf
bedingungs*LOS* immer und immer wieder ausgeführt werden soll, eine
Bedingung hinschreiben sollte, nur damit sie der Compiler bei der
Codegenerierung wieder entfernt.
Ich schreibe ja auch nicht
1
y=3+10*x*1+0;
obwohl ich fest davon ausgehen kann, dass das "* 1" und das "+ 0" vom
Compiler wegoptimiert wird.
Also lasse ich bei Endlosschleifen auch in Zukunft die Bedingung weg und
verwende deswegen weiterhin
Yalu X. schrieb:> Irgendeiner der mir zur Verfügung stehenden Compiler (ich weiß nicht> mehr genau, welcher), nahm das while(1) tatsächlich wörtlich und> erzeugte Code, der zuerst eine 1 in ein Register lud, dieses Register> auf 0 prüfte und abhängig vom Ergebnis aus der Schleife heraussprang.
Das war dann im letzten Jahrtausend.
> Trotzdem frage ich mich, warum man für eine Schleife, deren Rumpf> bedingungs*LOS* immer und immer wieder ausgeführt werden soll, eine> Bedingung hinschreiben sollte, nur damit sie der Compiler bei der> Codegenerierung wieder entfernt.
Bedingungs*los* ist es ja nicht... Die Bedingung ist eben immer wahr.
Bei for(;;) ist verwirrend, das eine leere Bedingung akzeptiert wird,
und diese immer wahr ist. Auch nicht intuitiv.
Johann L. schrieb:> Auch nicht intuitiv.
Meine Sprachgefühl und C lagen von Anfang an nicht so ganz in Deckung.
Lernen muss man die Sprache ohnehin, gerade auch hinsichtlich dessen,
was nicht ins Auge springt, wie undefined/unspeficied/... behaviour und
Umgang mit Typen verschiedener Breite. Da kommt es auf solchen Pipifax
wirklich nicht an.
Hallo,
das wollte ich auch soeben als Gegenkommentar schreiben. :-)
for benötigt auch eine Bedingung und für Endlos eben eine leere
Bedingung. Nur was ist eine leere Bedingung? Was will der Programmierer
mit "nichts" ausdrücken? Fragen über Fragen und deshalb wird es im
Forum auch ständig zu der Nachfrage kommen was for(;;) sein soll, wenn
das jemand liest.
Mit while(1) ist klar erkennbar das der Programmierer die Bedingung mit
"immer wahr" eindeutig konstant festgelegt hat. Das ist meine Logik.
> Ich schreibe ja auch nicht> y = 3 + 10 x 1 + 0;
Und selbst das kann sinnvoll sein, wenn man eine Formel mit
Wiedererkennungswert niederschreiben möchte. Pauschal ablehnen würde ich
sowas nicht.
Veit D. schrieb:> Und selbst das kann sinnvoll sein
Bei Mikrocontrollern kann es viel Sinn ergeben, wenn man eine 0 um N
Stellen nach links schiebt: ctrlreg = 1<<BITX | 0<<BITY.
> Bedingungs*los* ist es ja nicht...
Doch, das ist bedingungslos aka ein unconditional jump, also ein "goto".
"goto" hat hier gegenüber der entkernten Schleife den Vorteil das wegen
der Sprung-Marke der Umfang der Schleife klar erkennbar ist.
Bei einer (verschachtelten) Schleife dagegen muss man genau öffnende {
und schliessende Block-token} zählen. Das ist fehlerträchtig.
Besteht man aber darauf das es es doch eine Bedingung wäre die aber
zwanghaft true ist fabriziert man längeren Pseudocode, bspw.
CLEAR Reg
JMPZ Reg,L_START;
statt:
JMP L_START
Harald K. schrieb:> while (1)> {> label:> if (1)> continue;> else> continue;> goto label;> }
Den Fall, dass das goto nicht immer richtig funktioniert (Strahlen und
so!) würde ich auf jeden Fall noch mit abfangen:
MaWin O. schrieb:> Strahlen und so!
Die schaden bei sowas nur dem ohnehin schon vorverstrahlten
Programmierer. Die Hardware sieht nur den Binärcode, und der ist der
gleiche. ;-)
Johann L. schrieb:> Yalu X. schrieb:>>> Irgendeiner der mir zur Verfügung stehenden Compiler (ich weiß nicht>> mehr genau, welcher), nahm das while(1) tatsächlich wörtlich und>> erzeugte Code, der zuerst eine 1 in ein Register lud, dieses Register>> auf 0 prüfte und abhängig vom Ergebnis aus der Schleife heraussprang.>> Das war dann im letzten Jahrtausend.
Damals hatte ich auch mal einen Compiler, dessen Name ich nicht mehr
weiß: was ich aber noch ganz genau weiß,dass es für/while(true)/ den
optimalen Code erzeugt hat.
>> Trotzdem frage ich mich, warum man für eine Schleife, deren Rumpf>> bedingungs*LOS* immer und immer wieder ausgeführt werden soll, eine>> Bedingung hinschreiben sollte, nur damit sie der Compiler bei der>> Codegenerierung wieder entfernt.>> Bedingungs*los* ist es ja nicht... Die Bedingung ist eben immer wahr.
Das hatte ich oben schonmal geschrieben.
>> Bei for(;;) ist verwirrend, das eine leere Bedingung akzeptiert wird,> und diese immer wahr ist. Auch nicht intuitiv.
Auch das hätte ich oben angemerkt: es steht irgendwo versteckt im
C-Standard drin, und mitnichten intuitiv.
Man könnte genauso gut argumentieren, dass diese nicht vorhandene
Bedingung zu false evaluiert, um unbeabsichtigte Endlos-Iterationen zu
verhindern.
Wer ›goto‹ nachmacht oder verfälscht, oder nachgemachtes oder
verfälschtes ›goto‹ in Umlauf bringt, wird mit BASIC nicht unter drei
Portionen bestraft!
Parabelförmig vomittierend…
Johann L. schrieb:> Yalu X. schrieb:>>> Irgendeiner der mir zur Verfügung stehenden Compiler (ich weiß nicht>> mehr genau, welcher), nahm das while(1) tatsächlich wörtlich und>> erzeugte Code, der zuerst eine 1 in ein Register lud, dieses Register>> auf 0 prüfte und abhängig vom Ergebnis aus der Schleife heraussprang.>> Das war dann im letzten Jahrtausend.
Richtig:
Yalu X. schrieb:> nach der Lektüre des K&R (1. Auflage)
Das Buch habe ich zuvor neu im Buchhandel erworben :)
Johann L. schrieb:>> Trotzdem frage ich mich, warum man für eine Schleife, deren Rumpf>> bedingungs*LOS* immer und immer wieder ausgeführt werden soll, eine>> Bedingung hinschreiben sollte, nur damit sie der Compiler bei der>> Codegenerierung wieder entfernt.>> Bedingungs*los* ist es ja nicht... Die Bedingung ist eben immer wahr.
Zumindest in meinen Augen ist es bedingungslos, da die Ausführung des
Schleifenrumpfs immer erfolgt soll, also an keinerlei Bedingungen
geknüpft ist. Das true oder die 1 als Bedingungen kommt erst ins Spiel,
wenn man die Ausführung einer Anweisung eigentlich nicht an eine
Bedingung knüpfen möchte, aus rein formalen Gründen aber eine solche
verlangt wird. Genau dies ist bei while() der Fall, weil es die
Grammatik von C so vorschreibt, nicht aber bei for(), wo die Bedingung
optional ist.
Man könnte sich ein "cC" (conditional C) vorstellen, wo grundsätzlich
jede Anweisung an eine Bedingung geknüpft ist. Das würde dann bspw. so
aussehen:
1
x<lower_limit:>x=lower_limit;
2
x>upper_limit:>x=upper_limit;
3
true:>printf("lower_limit = %d\n",lower_limit);
4
true:>printf("x = %d\n",x);
5
true:>printf("upper_limit = %d\n",upper_limit);
In den ersten beiden Anweisungen ist die Bedingung erwünscht, die drei
nachfolgenden sollen aber bedingungslos ausgeführt werden. Die Grammatik
der Sprache verlangt aber nach einer Bedingung, also schreibt man eben
jeweils ein "true" hin, um den Compiler zufriedenzustellen. Wäre es
nicht schön, wenn die Bedingung optional wäre, so dass man den Code wie
folgt schreiben könnte:
1
x<lower_limit:>x=lower_limit;
2
x>upper_limit:>x=upper_limit;
3
printf("lower_limit = %d\n",lower_limit);
4
printf("x = %d\n",x);
5
printf("upper_limit = %d\n",upper_limit);
Oder meinst du, die drei leeren Bedingungen könnten von jemandem als
"false" interpretiert werden, was bedeuten würde, dass die printfs nie
ausgeführt würden?
cC ist zwar eine hypothetische Sprache, aber in ARM-Assembler kann fast
jede Instruktion bedingt ausgeführt werden (was natürlich auch von der
CPU-Hardware unterstützt wird), wobei die Bedingung durch einen
Zweizeichensuffix festgelegt wird, bspw.
1
MOVEQ ... ; Ausführung nur, wenn Z-Flag gesetzt ist
2
MOVHI ... ; Ausführung nur, wenn C-Flag gesetzt und Z-Flag gelöscht ist
3
MOVAL ... ; Ausführung immer (ALways)
4
MOV ... ; Ausführung immer
Der "AL"-Suffix entspricht also dem "true". Der Bedingungssuffix ist
optional. Wenn man ihn weglässt, wird die Instruktion immer ausgeführt.
Ich habe noch von niemandem gehört, der bei der bedingungslosen
Ausführung von Instruktionen auf dem "AL" bestehen würde mit der
Begründung, dass das Weglassen ja auch bedeuten könnte, dass die
Ausführung unterbunden wird.
Ja, ich weiß, die ganze Diskussion um das while(1) vs for(;;) ist
relativ müßig, und ich spucke ja auch niemanden an, der while(1)
verwendet ;-)
Yalu X. schrieb:> Zumindest in meinen Augen ist es bedingungslos, da die Ausführung des> Schleifenrumpfs immer erfolgt soll, also an keinerlei Bedingungen> geknüpft ist.
Für mich bedeutet das Fehlen der Bedingung, dass per Zufall entschieden
wird, ob die Schleife weiterläuft.
MaWin O. schrieb:> Für mich bedeutet das Fehlen der Bedingung, dass per Zufall entschieden> wird, ob die Schleife weiterläuft.
Weise Männer haben dereinst die sogenannten ›defaults‹ erfunden. Scheint
sich bewährt zu haben.
Norbert schrieb:> Weise Männer haben dereinst die sogenannten ›defaults‹ erfunden. Scheint> sich bewährt zu haben.
Was sind ›defaults‹?
Für mich ist die Sache glasklar: Durch das Auslassen der Bedingung
kommuniziert der Programmierer eindeutig, dass es ihm egal ist, unter
welcher Bedingung der Code ausgeführt wird (oder eben nicht ausgeführt
wird).
Eine konforme und zudem noch faire Implementierung dessen wäre die
Entscheidung per Zufallsgenerator.
MaWin O. schrieb:> Für mich bedeutet das Fehlen der Bedingung, dass per Zufall entschieden> wird, ob die Schleife weiterläuft.
Da du diese Aussage nicht an eine Bedingung (auch nicht an die immer
wahre) geknüpft hast, bleibt es also undefiniert, ob du sie wirklich so
meinst oder nicht ;-)
MaWin O. schrieb:> Eine konforme und zudem noch faire Implementierung dessen wäre die> Entscheidung per Zufallsgenerator.
Ok, ich habe gerade eine Münze entscheiden lassen. Ergebnis: Kopf. Also
meinst du das Gegenteil von dem, was du geschrieben hast ;-)
MaWin O. schrieb:> Was sind ›defaults‹?
Wo wir schon so Top-seriös bei Sache sind: wenn dir das Geld für eigene
Recherchen ausgegangen ist: Zahlungsverzug oder -Einstellung.
Norbert schrieb:> Möchtest du dafür gerne ein ›Let me google that for you‹ haben?
Nein. Aber dann scheint es ja unwichtig zu sein, wenn du es nicht einmal
für nötig hältst das kurz zu erklären.
Yalu X. schrieb:> Zumindest in meinen Augen ist es bedingungslos, da die Ausführung des> Schleifenrumpfs immer erfolgt soll, also an keinerlei Bedingungen> geknüpft ist.
Der TO ist das beste Beispiel dafür, dass das keineswegs klar ist.
Schreibt man es explizit hin, ist es doch sofort jedem klar! Wie gesagt:
wie in ganz vielen anderen Fällen ist explizit besser als implizit.
Yalu X. schrieb:> Ja, ich weiß, die ganze Diskussion um das while(1) vs for(;;) ist> relativ müßig, und ich spucke ja auch niemanden an, der while(1)> verwendet ;-)
Nach dem Sermon, den Du dazu schreibst, bin ich mir da gerade nicht so
sicher ...
Wilhelm M. schrieb:> Yalu X. schrieb:>> Zumindest in meinen Augen ist es bedingungslos, da die Ausführung des>> Schleifenrumpfs immer erfolgt soll, also an keinerlei Bedingungen>> geknüpft ist.>> Der TO ist das beste Beispiel dafür, dass das keineswegs klar ist.
Einer, der noch kein C-Buch durchgearbeitet hat, wird beim erstmaligen
Anblick von
1
while(1){
2
...
3
}
fragen: "Häh, was soll denn diese Schleife mit nur 1 Durchlauf? Warum
lässt man das while nicht einfach weg?"
Ich meine mich vage erinnern zu können, dass wir hier im Forum sogar
tatsächlich einmal einen ähnlichen Fall hatten.
Yalu X. schrieb:> Einer, der noch kein C-Buch durchgearbeitet hat, wird beim erstmaligen> Anblick von> while (1) {> ...> }
Wer schreibt denn heute noch so einen Blödsinn? Seit C99 heißt das
while(true).
Wilhelm M. schrieb:> Yalu X. schrieb:>> Einer, der noch kein C-Buch durchgearbeitet hat, wird beim erstmaligen>> Anblick von>> while (1) {>> ...>> }>> Wer schreibt denn heute noch so einen Blödsinn? Seit C99 heißt das> while(true).
Der Code, den der unwissende Anfänger vorgesetzt bekommt, könnte auch
schon älter sein.
Yalu X. schrieb:> Der Code, den der unwissende Anfänger vorgesetzt bekommt, könnte auch> schon älter sein.
In welchem Buch, etc. wird denn die /while/-Iteration mit einer
Zählschleife assoziiert? Jeder, der ein C-Buch mal in der Hand hatte,
weiß, dass dem nicht so ist. Die "Zählschleife" ist die /for/-loop.
Die Frage, die hier eigentlich nach dem Lesen des Buches entstehen
sollte, was ist denn "1" für ein Boole'scher Ausdruck? Ist damit "true"
gemeint?
(prx) A. K. schrieb:> K&R erste Fassung von 1978. Wer das durchlas, konnte es kaum übersehen.> Wer nicht, war selber Schuld.
Interessant, also ein leerer zweite Term genügt für ne endlos-schleife?!
Na dann, schauen wir mal wie schnell Chuck Norris mit unendlich durch
ist:
for (int *pt = malloc(0);;pt++) {}
o.ä.
Wilhelm M. schrieb:> Die Frage, die hier eigentlich nach dem Lesen des Buches entstehen> sollte, was ist denn "1" für ein Boole'scher Ausdruck?
Wenn man sich länger als fünf Minuten mit C beschäftigt haben sollte,
ist das keine Frage, die entsteht.
Wilhelm M. schrieb:> Yalu X. schrieb:>> Der Code, den der unwissende Anfänger vorgesetzt bekommt, könnte auch>> schon älter sein.>> In welchem Buch, etc. wird denn die /while/-Iteration mit einer> Zählschleife assoziiert?Yalu X. schrieb:> Einer, der noch kein C-Buch durchgearbeitet hat, ...
Du hast offensichtlich das Wörtchen "kein" überlesen. Einer, der das
Buch gelesen hat, weiß das natürlich. Er weiß dann aber auch, was
for(;;) bedeutet.
Yalu X. schrieb:> Du hast offensichtlich das Wörtchen "kein" überlesen.
Nein. Warum sollte denn der Ausdruck bei while die Anzahl(!) der
Durchläufe sein.
In deutsch: solange(1).
Wer kommt dabei auf die Idee, dass "1" die Anzahl der Iterationen sein
sollte?
Wilhelm M. schrieb:> Yalu X. schrieb:>> Du hast offensichtlich das Wörtchen "kein" überlesen.>> Nein. Warum sollte denn der Ausdruck bei while die Anzahl(!) der> Durchläufe sein.
Vielleicht, weil es jemand nicht besser weiß? Er sieht ein "while" und
hat vielleicht schon einmal irgendwoher gehört, dass das mit einer
Schleife zu tun hat. Dann sieht er noch eine Zahl (in diesem Fall die
1), und überlegt, welche Bedeutung eine Zahl im Schleifenkopf haben
könnte. Da ist es doch durchaus naheliegend, dass das die Anzahl der
Durchläufe sein könnte.
> In deutsch: solange(1).
Wer versucht, Programmcode zu verstehen, indem er ihn ins Deutsche
übersetzt, hat schon von vornherein verloren. Aus deinem favorisierten
while(true) würde solange(wahr). Ohne entsprechendes Vorwissen (bspw.
aus einem Buch) ist das so verständlich wie vorgestern(joghurtbecher).
Wilhelm M. schrieb:> Der TO ist das beste Beispiel dafür, dass das keineswegs klar ist.>
Jetzt muss ich doch noch anmerken, dass es mir schon klar war, dass es
sich um eine Endlosschleife handeln musste, nur gesehen hatte ich bisher
for(;;) noch nie. Die Firmware von Microchip, anfangs von mir erwähnt,
habe ich für meine Bedürfnisse abgeändert und sie funktioniert. Sie
treibt seit drei Jahren einen BLDC-Motor an.
Apropos bedingt, unbedingt:
Folgende Bedingung musste ich in eine andere Schleife einbinden, um den
Controller auszuschalten:
while(!PORTBbits.RB2)
{
blabla;
}
Yalu X. schrieb:> Wilhelm M. schrieb:>> Yalu X. schrieb:>>> Du hast offensichtlich das Wörtchen "kein" überlesen.>>>> Nein. Warum sollte denn der Ausdruck bei while die Anzahl(!) der>> Durchläufe sein.>> Vielleicht, weil es jemand nicht besser weiß?
Und derjenige weiß dann, dass for(;;) einen impliziten Bedingungsteil
hat, der immer true ist. Das glaubst Du doch selbst nicht.
>> In deutsch: solange(1).> Wer versucht, Programmcode zu verstehen, indem er ihn ins Deutsche> übersetzt, hat schon von vornherein verloren. Aus deinem favorisierten> while(true) würde solange(wahr).
Genau. Und das halte ich für ziemlich selbsterklärend.
Jan S. schrieb:> Jetzt muss ich doch noch anmerken, dass es mir schon klar war, dass es> sich um eine Endlosschleife handeln musste, nur gesehen hatte ich bisher> for(;;) noch nie.
Du hast es also aus dem Kontext geschlossen ...
Wilhelm M. schrieb:> Jan S. schrieb:>> Jetzt muss ich doch noch anmerken, dass es mir schon klar war, dass es>> sich um eine Endlosschleife handeln musste, nur gesehen hatte ich bisher>> for(;;) noch nie.>> Du hast es also aus dem Kontext geschlossen ...
Ja, die Firmware, die ich abgeändert habe, stammt aus einer noch älteren
Firmware als der anfangs gepostete Codeschnipsel. Im älteren
Codeschnipsel benutzte der Programmierer while(1){}.
Gruss Jan
Wilhelm M. schrieb:> Und derjenige weiß dann, dass for(;;) einen impliziten Bedingungsteil> hat, der immer true ist. Das glaubst Du doch selbst nicht.
Das einer, der noch kein C-Buch gelesen hat, das for- leichter als das
while-Konstrukt versteht, habe ich nirgends behauptet. Wenn er aber erst
einmal weiß, was die drei Teile der for-Schleifenkopfs bedeuten, wird er
aus dem Fehlen des mittleren Teils schließen, dass der Programmierer
keine Bedingung für die Ausführung des Schleifenrumpfs vorgesehen hat,
offensichtlich mit der Absicht, dass dieser bedingungslos, d.h. ohne
Einschränkungen ausgeführt wird. Fertig. Das ist alles, was er wissen
muss.
Er muss, um zu diesem Schluss zu kommen, nicht den Umweg über die
implizite, immer true liefernde Bedingung gehen, sondern den Begriff
"Bedingung" genauso wie im normalen Sprachgebrauch betrachten: Wenn ich
im realen Leben jemandem eine Zusage mache und knüpfe diese an keinerlei
Bedingung, dann lasse ich diese einfach weg.
Beispiel:
Zusage mit Bedingung:
"Wenn es schönes Wetter wird, werde ich dich morgen besuchen."
Zusage ohne Bedingung:
"Ich werde dich morgen besuchen."
und nicht etwa
"Wenn die immer erfüllte Bedingung erfüllt ist, werde ich dich morgen
besuchen."
oder
"Wenn wahr, werde ich dich morgen besuchen."
Es kann natürlich sein, dass dein Sprachgebrauch ein anderer ist als
meiner. Dann werde ich das natürlich akzeptieren.
Yalu X. schrieb:> aus dem Fehlen des mittleren Teils schließen, dass der Programmierer> keine Bedingung für die Ausführung des Schleifenrumpfs vorgesehen hat,> offensichtlich mit der Absicht, dass dieser bedingungslos
Eine Schleife wird aber leider nicht mit 'loop' eingeleitet, sondern mit
'for'.
for(;;)? for what? Das ergibt überhaupt keinen Sinn und gehört auf den
Müllhaufen der Geschichte.
Hallo,
eigentlich ist es mir ja egal wer was wie schreibt. Es ist nur
erschreckend mitzulesen was für abstruse Begründungen hier aufgefahren
werden um seine Ansicht irgendwie zu begründen. Wenn K&R damals for (;;)
nicht als Endlosschleife irgendwo niedergeschrieben hätten, wüßte bis
heute niemand das dieses unklare Konstrukt zur Endlosschleife mutiert.
Denn das geht aus der "for" Beschreibung allein nicht hervor. Das
for(;;) wird extra beschrieben das es eine Endlosschleife ist. Da kommt
sonst niemand drauf. Im Nachgang werden sich dann komische Begründungen
ausgedacht um das zurechtfertigen, wie man im Thread sehr schön
beobachten kann. Darüber muss ich mich schon sehr stark wundern. Im
Gegensatz zu while. Hieraus geht aus der Beschreibung schon hervor
solange die Bedingung wahr ist werden die Anweisungen wiederholt
ausgeführt.
> und nicht etwa> "Wenn die immer erfüllte Bedingung erfüllt ist, werde ich dich morgen> besuchen."
Tut mir leid, will dir nicht zu Nahe treten, aber ist auch nur eine
abstruse Begründung, eine verdrehte Satzbildung, dafür das du while eben
nicht leiden kannst und nicht akzeptierst.
Denn es muss lauten wie es im Lehrbuch steht.
Wenn die Bedingung erfüllt ist, werde ich dich morgen besuchen.
Oder besser.
Solange die Bedingung erfüllt ist, werde ich dich morgen besuchen.
Wie gesagt, verwendet was ihr wollt, aber hört auf Euch irgendwelche
lächerlichen Begründungen für irgendwas auszudenken. Nur weil K&R damals
nichts besseres einfiel und ihr das nun gewohnt seit und verwendet. Der
Fortschritt lebt davon eingeschliffene Dinge zu hinterfragen. Die
gesamte Haarspalterei im Thread ist lächerlich.
Ahmen.
Veit D. schrieb:> Im Nachgang werden sich dann komische Begründungen ausgedacht um das> zurechtfertigen, wie man im Thread sehr schön beobachten kann.
Ja, irgendwie muss der Thread doch seine Endlosschleife hier weiter
fahren, oder?
Yalu X. schrieb:> ...> Er muss, um zu diesem Schluss zu kommen, nicht den Umweg über die> implizite, immer true liefernde Bedingung gehen, sondern den Begriff> "Bedingung" genauso wie im normalen Sprachgebrauch betrachten: Wenn ich> im realen Leben jemandem eine Zusage mache und knüpfe diese an keinerlei> Bedingung, dann lasse ich diese einfach weg.>> Beispiel:> "Wenn wahr, werde ich dich morgen besuchen.">> Es kann natürlich sein, dass dein Sprachgebrauch ein anderer ist als> meiner. Dann werde ich das natürlich akzeptieren.Yalu X. schrieb:> Wer versucht, Programmcode zu verstehen, indem er ihn ins Deutsche> übersetzt, hat schon von vornherein verloren. Aus deinem favorisierten> while(true) würde solange(wahr). Ohne entsprechendes Vorwissen (bspw.> aus einem Buch) ist das so verständlich wie vorgestern(joghurtbecher).
Yalu X. schrieb:> Yalu X. schrieb:>> nach der Lektüre des K&R (1. Auflage)
Ich bezweifle, dass dieses Buch heute noch gelesen wird. Und doch, würde
ich dem Kandidaten empfehlen, damit aufzuhören.
Sonst diskutieren wird demnächst noch über die Funktionsdeklaration im
K&R-Stil bzw. darüber, dass es doch viel einfacher sei, eine Deklaration
ohne Parameterliste zu schreiben, und das es eben besser sei, nur
Funktionen zu deklarieren, die kein int zurück geben.
Je länger Eure Begründungstexte werden, desto abstruster werden sie.
Jan S. schrieb:> Wilhelm M. schrieb:>> Jan S. schrieb:>>> Jetzt muss ich doch noch anmerken, dass es mir schon klar war, dass es>>> sich um eine Endlosschleife handeln musste, nur gesehen hatte ich bisher>>> for(;;) noch nie.>>>> Du hast es also aus dem Kontext geschlossen ...> Ja, die Firmware, die ich abgeändert habe, stammt aus einer noch älteren> Firmware als der anfangs gepostete Codeschnipsel. Im älteren> Codeschnipsel benutzte der Programmierer while(1){}.> Gruss Jan
Intressant:
ursprünglich stand dort also ein while, dass irgendjemand zu einem
/for(;;)/ verschlimmbessert hat. Und das machte dann Deine
Verständnisschwierigkeiten.
> Wenn er aber erst> einmal weiß, was die drei Teile der for-Schleifenkopfs bedeuten, wird er> aus dem Fehlen des mittleren Teils schließen, dass der Programmierer> keine Bedingung für die Ausführung des Schleifenrumpfs vorgesehen hat,> offensichtlich mit der Absicht, dass dieser bedingungslos, d.h. ohne> Einschränkungen ausgeführt wird. Fertig.
.. ist der Syntax-fehler.
OK, hier gerade nicht, aber eben nur weil der Compiler die
Zusatzanforderung - nichts angegeben, ist das gleich wie 1 == 1
reingeschrieben - kennt. An allen möglichen Stellen meckert/warnt der
Compiler, das hier und da dem Syntax irgendetwas fehlen könnte (i.e.
"Read before written" oder if (a = 0)) aber in diesem Semikolonsalat
zaubert er irgendeine prähistorische Regel aus dem Hut, die
Alltagsdenken komplett widerspricht ("Mach etwas bis in alle Ewigkeit
auch wenn Du nicht explizit dazu aufgeforderst wird").
Siehe auch:
https://youtu.be/NgUSe5JpdoU?t=10
Für den Alltag dagegen lernt man, das "nichts sagen" auch nichts
bedeutet (rechtliches Nullum).
https://de.wikipedia.org/wiki/Schweigen_(Recht)
Wer aus dem Fehlen von Angaben auf irgendetwas schliessen will, sollte
wegen aufkeimenden verfolgungswahn zum Psychiater gehen.
Veit D. schrieb:> Wie gesagt, verwendet was ihr wollt, aber hört auf Euch irgendwelche> lächerlichen Begründungen für irgendwas auszudenken. Nur weil K&R damals> nichts besseres einfiel und ihr das nun gewohnt seit und verwendet.
Sehe ich auch so, hatte ich oben so geschrieben:
Wilhelm M. schrieb:> Hört sich fast so an, als wärt ihr katholisch: nur weil das vor Äonen> schon mal im K&R stand, bedeutet das (für mich) nicht, dass man das so> machen sollte. Ich denke da lieber selbst ;-)
Ist das die arabische Version von Amen ?
> Ahmen.
Wilhelm M. schrieb:> Je länger Eure Begründungstexte werden, desto abstruster werden sie.
Das ist der Sinn der Sache. Kann man fehlenden Humor eigentlich
nachlernen, oder muss man für den Rest des Lebens mit dem zurecht
kommen, was man in der Kindheit verpasste?
[offtopic]
> Ist das die arabische Version von Amen ?>> Ahmen.
Amen ist schon vom Wortursprung her arabisch resp. semitisch.
https://de.wikipedia.org/wiki/Amen#Etymologie
Lediglich die Schreibweisen variieren je nach bevorzugten Schriftsatz:
Lautschrift [ˈaːmɛn], hebräisch אָמֵן, altgriechisch ἀμήν, arabisch
آمين
[/offtopic]
DSGV-Violator schrieb:> [offtopic]>>> Ist das die arabische Version von Amen ?>>> Ahmen.>> Amen ist schon vom Wortursprung her arabisch resp. semitisch.
Danke, aber das es hebräisch ist, war mir schon klar.
> Lediglich die Schreibweisen variieren je nach bevorzugten Schriftsatz:> Lautschrift [ˈaːmɛn], hebräisch אָמֵן, altgriechisch ἀμήν, arabisch> آمين
Wikipedia kann ich selber lesen ;-)
Und in deutsch wird es üblicherweise als "Amen" geschrieben.
Wilhelm M. schrieb:> Und in deutsch wird es üblicherweise als "Amen" geschrieben.
Keine Sorge, das kommt noch. Sprache pflegt sich den veränderten
Gegebenheiten anzupassen.
MaWin O. schrieb:> Yalu X. schrieb:>> aus dem Fehlen des mittleren Teils schließen, dass der Programmierer>> keine Bedingung für die Ausführung des Schleifenrumpfs vorgesehen hat,>> offensichtlich mit der Absicht, dass dieser bedingungslos>> Eine Schleife wird aber leider nicht mit 'loop' eingeleitet, sondern mit> 'for'.
Da stimme ich dir zu. Mit "loop" wäre das Ganze noch ein Stückchen
besser. Und bei while(true) könnte dann wie in Rust eine Warning (oder
noch besser ein Error) ausgegeben werden.
Wilhelm würde aber vermutlich auch loop ablehnen mit der Begründung,
dass loop nichts anderes als while(true) mit einer böswillig
versteckten, impliziten und immer wahren Bedingung ist ;-)
Das ist ja mal ein ungewöhnlich lehrreicher Thread. Ich lerne daraus:
Endlosschleifen sind den Aufwand nicht wert, man verwendet einen
Thread/Task/Prozess, der immer wieder neu gestartet wird. Im
"Betriebssystem" darf es sowieso keine Endlosschleife geben, Problem
gelöst ;)
177 (178 jetzt) Beiträge über for (;;){} - DAS Anfängerstatement in C an
sich.
Dieses Forum ist so was von krank. Diskussion über die Endlosschleife in
einer Endlosschleife. Man könnte noch einen neuen Fred aufmachen, wo man
über die endlose Diskussion über die Diskussion der Endlosschleife
diskutiert?
Harald K. schrieb:> Erwähnte ich schon die beeindruckende Dichte geistiger Onanie in diesem> Thread hier?
Ja, jetzt schon zum dritten Mal. Das wird doch nicht etwa eine
Endlosschleife?
Bauform B. schrieb:> Im> "Betriebssystem" darf es sowieso keine Endlosschleife geben, Problem> gelöst ;)
Ich betrachte die ganz am Anfang gepostete Schleife als unbedingt
notwendig, sie ist das eigentliche "Betriebssystem", sie fragt pausenlos
den Zustand des Tasters ab, der restliche Betrieb läuft praktisch nur
noch über Interrupts.
Jan S. schrieb:> Bauform B. schrieb:>> Im>> "Betriebssystem" darf es sowieso keine Endlosschleife geben, Problem>> gelöst ;)>> Ich betrachte die ganz am Anfang gepostete Schleife als unbedingt> notwendig, sie ist das eigentliche "Betriebssystem", sie fragt pausenlos> den Zustand des Tasters ab, der restliche Betrieb läuft praktisch nur> noch über Interrupts.
Und warum darf der Taster keinen Interrupt liefern?
Bauform B. schrieb:> Und warum darf der Taster keinen Interrupt liefern?
Das könnte man schon auch über einen Interrupt machen, dann wäre das
Programm(oder "Betriebssystem") eine leere Endlosschleife.
Yalu X. schrieb:> MaWin O. schrieb:>> Yalu X. schrieb:>>> aus dem Fehlen des mittleren Teils schließen, dass der Programmierer>>> keine Bedingung für die Ausführung des Schleifenrumpfs vorgesehen hat,>>> offensichtlich mit der Absicht, dass dieser bedingungslos>>>> Eine Schleife wird aber leider nicht mit 'loop' eingeleitet, sondern mit>> 'for'.>> Da stimme ich dir zu. Mit "loop" wäre das Ganze noch ein Stückchen> besser. Und bei while(true) könnte dann wie in Rust eine Warning (oder> noch besser ein Error) ausgegeben werden.>> Wilhelm würde aber vermutlich auch loop ablehnen mit der Begründung,> dass loop nichts anderes als while(true) mit einer böswillig> versteckten, impliziten und immer wahren Bedingung ist ;-)
Wieso sollte ich das ablehnen? Anscheinend hast Du immer noch gar nichts
verstanden.
Ein
> wäre doch super.
Aber nur in einem mickrigen Drei-Zeilen Codeschnipsel.
Erstreckt sich der Schleifenköper aber über mehr als nur 40 Zeilen und
umschliesst als Schachtel weitere Blöcke und steckt womöglich selbst in
ein paar verschachtelten Schachtel-Blöcken reichen '{' und '}' als
Orientierung für Anfang und Ende nicht aus. Da sind Label und oder
comments handreichender. Aber offensihtlich sind Labels wie goto die
ungeliebten Stiefkinder in C.
https://www.geeksforgeeks.org/local-labels-in-c/
for(;;) musste ich erst nachschlagen und macht für mich auch keinen
wirklichen Sinn weil ich nicht davon ausgehen kann, dass das weglassen
von Argumenten automatisch zu einer Endlosschleife führt. Ohne Internet
wäre ich also aufgeschmissen.
while(1) oder while(true) ist auf Anhieb klar, wenn man halbwegs weiß
wie while funktioniert.
Ich schreibe daher auch
Hallo,
Veit D. schrieb:> Wenn K&R damals for (;;) nicht als Endlosschleife irgendwo> niedergeschrieben hätten...
Tja, haben sie eigentlich gar nicht. Ich habe mal in in der deutschen
Übersetzung von "Programmieren in C" von 1990 nachgesehen. Da wird in
Kapitel 3.5 "Schleifen - while und /for/" die entsprechende Syntax
beschrieben und darauf hingewiesen das beide Schleifenkonstrukte
zueinander äquivalent sind:
1
for ( expr1 ; expr2 ; expr3 )
2
statement
ist äquivalent zu
1
expr1 ;
2
while ( expr2 ) {
3
statement;
4
expr3;
5
}
Weiterhin heißt es (wurde hier auch schon des Öfteren erwähnt): "Fehlt
die Bedingung expr2, so gilt sie immer als wahr". Als _*Beispiel*_ wird
jetzt
1
for (;;) {
2
...
3
}
angeführt, Zitat "...ist also eine 'unendliche Schleife', die vermutlich
durch Anweisungen wie break oder return beendet wird". Und weiter
heißt es :"Ob man while oder for bevorzugt, beruht weitgehend auf
persönlicher Vorliebe."
Ich habe auch nirgend wo sonst im Buch eine explizite Forderung gefunden
das man für Endlosschleifen das for()-Konstrukt zu verwenden hat. Es
bleibt also jedem selbst überlassen welches Konstrukt er für seine
"Endlosschleifen" benutzt.
> ...wüßte bis heute niemand das dieses unklare Konstrukt zur> Endlosschleife mutiert.
Ich weiß noch genau wie ich zum ersten mal eine while(1) in einem
Quelltext gesehen und ich mich gewundert habe wie das funktioniert wo
doch der sonst üblich Vergleichsausdruck fehlt. Auch heute noch finde
ich diese Form der Endlosschleife merkwürdig, unlogisch und für einen
Anfänger schwer zu verstehen.
rhf
P.S.
Und im Übrigen bin ich der Meinung, das die Konstruktion von
Endlosschleifen mit while() oder for() die eigentliche Funktion
verschleiert. Deshalb ist für mich die einzig wahre Konstruktion die
mit
1
Label:
2
...
3
goto Label
Wenn dann noch Label entsprechend benannt wird, weiß jeder sofort und
unmissverständlich was gemeint ist
Hallo,
Wilhelm M. schrieb:> Aufgrund der obigen Diskussion muss ich natürlich noch den C++-Vorschlag> von oben
Warum? Wozu ist das gut, wo es doch hier um eine for(;;) in C geht?
rhf
DSGV-Violator schrieb:> lies das Buch über Endlos geflochtene Bänder - in den Achtzigern> schaffte es dieses sogar Wochenlang auf die Spiegel-Bestsellerliste:
Ich fragte mich allerdings schon damals, wieviele derer, die es gekauft
hatten, es auch in signifikantem Umfang gelesen hatten.
(prx) A. K. schrieb:> DSGV-Violator schrieb:>> lies das Buch über Endlos geflochtene Bänder - in den Achtzigern>> schaffte es dieses sogar Wochenlang auf die Spiegel-Bestsellerliste:>> Ich fragte mich allerdings schon damals, wieviele derer, die es gekauft> hatten, es auch in signifikantem Umfang gelesen hatten.
Nun, das Bemerkenswerte an diesem Buch ist, dass sich, aufgrund der
zahlreichen Zeichnungen von, den Buchtitel mit-tragenden, Maurits
Cornelis Escher, ein Zugang allein durch Betrachtung der Illustration
eine Zugangsmöglichkeit ergibt.
Andere mögen sich das Buch über die Ausführungen zur Musikgeschichte
(Bach) erschliessen, persönlich führte der Weg über die Ausführungen zur
formalen Logik und (Östlicher) Philosophie.
Die Darstellungen zum maschinellen Rechnen/Computerei funktionieren da
anschauliche beispiele zu einem (sehr) abstrakten) Thema.
Aber das Buch ist tatsächlich keine kleine Kost die man so nebenher bei
der Fahrt im ÖPNV "wegfuttert". Manche lesen ein Leben lang immer mal
wieder darin. Fast so wie die "Bibelforscher" ;-)
(prx) A. K. schrieb:> Jan S. schrieb:>> Jetzt wollte ich es noch vom C30-Compiler von Microchip wissen>> Ernsthaft anders erwartet?
Nein, aber es gibt Gewissheit...
DSGV-Violator schrieb:> Aber nur in einem mickrigen Drei-Zeilen Codeschnipsel.> Erstreckt sich der Schleifenköper aber über mehr als nur 40 Zeilen und> umschliesst als Schachtel weitere Blöcke und steckt womöglich selbst in> ein paar verschachtelten Schachtel-Blöcken reichen '{' und '}' als> Orientierung für Anfang und Ende nicht aus.
Schon mal was von Funktionen gehört?
M. D. schrieb:> y = x > 9 ? 100 : 200;
Der ternäre Operator ist in C nur eine "verkümmperte Lambda-Expression"
und in einer Wertzuweisung schon fehl am Platz, weil ein normales
/if/-statement besser zu lesen ist. Er ist allerdings wichtig für
Initialisierungen von read-only Objekten, etwa:
Roland F. schrieb:> Tja, haben sie eigentlich gar nicht. Ich habe mal in in der deutschen> Übersetzung von "Programmieren in C" von 1990 nachgesehen. Da wird in> Kapitel 3.5 "Schleifen - while und /for/" die entsprechende Syntax> beschrieben und darauf hingewiesen das beide Schleifenkonstrukte> zueinander äquivalent sind:
Ach was, schon mal was von Schleifentransformation gehört?
Roland F. schrieb:> ch weiß noch genau wie ich zum ersten mal eine while(1) in einem> Quelltext gesehen und ich mich gewundert habe wie das funktioniert wo> doch der sonst üblich Vergleichsausdruck fehlt.
Das ganz einfach an dieser dummen Praxis while(1) statt besser
while(true) hinzuschreiben.
Wilhelm M. schrieb:> und in einer Wertzuweisung schon fehl am Platz, weil ein normales> /if/-statement besser zu lesen ist.
Es kann zum Glück auch auf den Misthaufen der Geschichte.
In Rust kann das if-statement beides.
> Das ganz einfach an dieser dummen Praxis while(1) statt besser> while(true) hinzuschreiben.
Naja, das Dumme ist, das Standard-C in der Praxis keine boolean Werte
wie 'true' kennt.
Ist halt einer der Geburtsfehler dieser Sprache. Oder eben nicht, kommt
darauf an, ob man C eher als gezuckerten Assembler für Embedded oder als
Hochsprache für Mathematisch-Abstrakte Aufgabenstellungen die sich wenig
um numerische Representation schert, versteht/benutzt.
Beitrag "Boolean in C"> Schon mal was von Funktionen gehört?
Klar, würde hier u.a. wegen Context-switch/Stack-Operationen das Problem
noch vergrößern statt verkleinern.
DSGV-Violator schrieb:> Naja, das Dumme ist das Standard-C in der Praxis keine boolean Werte wie> true kennt.
Ja, C ist in vielerlei Hinsicht dumm! Siehe for(;;).
DSGV-Violator schrieb:>> Schon mal was von Funktionen gehört?> Klar, würde hier u.a. wegen Context-switch/Stack-Operationen das Problem> noch vergrößern statt verkleinern.
Hä???
Thread beobachten
Seitenaufteilung abschalten