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ä???
DSGV-Violator schrieb:> Ich hau mich weg, das steht "removed in C23". Und> "Bequemlichkeits-Makro", die reinste Warmduscherei ..
Richtig, dafür ist es ab C23 ein eigener Typ.
MaWin O. schrieb:> DSGV-Violator schrieb:>> Ich hau mich weg>> Freut mich, dass du dich auch über kleine Dinge amüsieren kannst.
Über den Unterschied zwischen "Weg Hauen" und "Amüsement" müsste man
sich mal in Ruhe unterhalten ...
Ich finde es jedenfalls nicht hilfreich, das hier die Benutzung von
"abgeschnittenen Sonderlocken" aus Gründen der Bequemlichkeit
vorgeschlagen wird.
DSGV-Violator schrieb:> Ich finde es jedenfalls nicht hilfreich, das hier die Benutzung von> "abgeschnittenen Sonderlocken" aus Gründen der Bequemlichkeit> vorgeschlagen wird.
Kann es sein, dass es an deinem Leseverständnis hapert?
Wilhelm M. schrieb:>> Naja, das Dumme ist, das Standard-C in der Praxis keine boolean Werte>> wie 'true' kennt.> Mindestens seit C99 aber schon.> Richtig, dafür ist es ab C23 ein eigener Typ.
Alter Falter, nicht mal Jahreszahlen kriegt man hier richtig gebacken
...
Ja klar, in irgendeinem Standard von anno
"AchHatDerHundDieEckeMitDerJahreszahlGefressen" steht es so oder doch
anders und warum schreibt man überhaupt "Standards" wenn man diese wie
politische Parteien je nach Wahlkampf umfrisiert ...
Geburtsfehler ist nun mal Geburtsfehler, da kann auch plastische
Chirurgie nur den Anschein aufhübschen aber nicht den Wesenskern.
DSGV-Violator schrieb:> Alter Falter, nicht mal Jahreszahlen kriegt man hier richtig gebacken
Ab C99 gibt es bool, true und false, die sich wie echte Booleans
verhalten. Also nur die Werte 0 und 1 annehmen können. Was brauchst du
noch?
MaWin O. schrieb:> Ab C99 gibt es bool, true und false, die sich wie echte Booleans> verhalten. Also nur die Werte 0 und 1 annehmen können. Was brauchst du> noch?
Wie jetzt? Es muss doch heissen "nur die Werte zwischen 0.0 und 1.0".
Wie will man sonst die-ganze-Wahrheit von der einfachen Aussage
unterscheiden? Hier ist for(;;) auch wieder überlegen, weil, wie lange
läuft eine Endlosschleife while(true) mit true = 0.99?
DSGV-Violator schrieb:> Es gibt da schon einen Unterschied zwischen Sprache und> Standardbibliotheken.
Aus Sicht des Sprachstandards nicht wirklich, beides ist "the
implementation".
Dass man "true" und "false" so spät nicht einfach ohne Headerfile neu
definieren durfte, ist einfach mal den vielen existierenden Programmen
geschuldet, die sowas vorher selbst definiert haben durften. Der Typ
_Bool ist aber dennoch intrinisch, denn dessen Bezeichner liegt im
implementation namespace. <stdbool.h> mappt ihn dann nur auf bool.
Veit D. schrieb:> 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.
Das ist natürlich Quadratunsinn!
Im K&R steht es EXPLIZIT drin.
K&R Ed.2 page 56
Hans H. schrieb:> Ich schreibe die Endlosschleife immer so:> do {> // many> // lines> // of> // code> } while (1=1);>> denn ich finde die Überraschung muß am Ende kommen.
Parabelförmig vomittierend…
Wilhelm M. schrieb:> Ist das die arabische Version von Amen ?>> Ahmen.
Klarer Syntaxfehler von mir. Davor hätte mich bestimmt der Compiler
gewarnt. Mir fehlt nur noch eine Begründung wie man das doch noch als
Richtig erklären könnte. Dann wäre es Thread Konform. :-) :-)
Yalu X. schrieb:> 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 das meinte ich weiter oben, als ich davon sprach, dass es keine
richtige Bedingung sei. Technisch ist es natürlich eine Bedingung, aber
ich schreibe sie nur hin, weil sie eben formal nötig ist und nicht, weil
ich tatsächlich eine will.
DSGV-Violator schrieb:> 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
… dann sollte man sich mal schleunigst daran machen, den Code sauberer
zu strukturieren.
Wilhelm M. schrieb:> Auch das hätte ich oben angemerkt: es steht irgendwo versteckt im> C-Standard drin, und mitnichten intuitiv.
Wo das im C-Standard steht, wird für die wenigsten relevant sein, weil
sie da eh nicht reinschauen. Wichtiger ist, wo es im Lehrbuch steht, und
die Optionaliät der drei Ausrücke in einer for-Schleife wird da doch
hoffentlich im Kapitel über Schleifen drin stehen, sonst taugt es nicht
viel.
Und ich finde es im übrigen sehr wohl intuitiv, mehr noch als wenn ich
irgendwas als Bedingung hinschreiben muss, nur um der Form genüge zu
tun.
> Man könnte genauso gut argumentieren, dass diese nicht vorhandene> Bedingung zu false evaluiert, um unbeabsichtigte Endlos-Iterationen zu> verhindern.
Das wäre nun wirklich an den Haaren herbeigezogen. Warum hätten sie die
Bedingung dann überhaupt optional gemacht? Eine extra eingebaute
zusätzliche Option, nur um explizit Schleifen schreiben zu können, die
niemals ausgeführt werden? Das ergäbe nun wirklich gar keinen Sinn.
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.
Hier hat jetzt genau einer mal nachgefragt. Es gibt hier zu allerhand
Bestandteilen verschiedener Sprachen Fragen. Das bedeutet nicht, dass
das alles völlig unintuitiv 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.
Bis auf das "es" sind wir uns da einig. Für mich ist "es" die
Bedingungslosigkeit der Schleife, denn das ist es ja, was ich eigentlich
erreichen will. Und Bedingungslosigkeit drückt man am besten dadurch
aus, dass man keine Bedingung angibt.
Wilhelm M. schrieb:> iterate(Forever{})([]{> r *= 2;> });
Was lisp kann (Klammernorgien), das bekommen wir in C++ doch auch locker
hin. ;-)
Yalu X. schrieb:> 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?
Was er vergessen hat zu erwähnen ist, warum er eigentlich immer noch
mitliest, wenn er die Diskussion so blöd findet.
Rolf M. schrieb:> Bis auf das "es" sind wir uns da einig. Für mich ist "es" die> Bedingungslosigkeit der Schleife, denn das ist es ja, was ich eigentlich> erreichen will.
Wenn Du explizit das Fehlen von etwas hinschreiben möchtest, dann
brauchst Du dafür eben ein Konstrukt, was Du schreiben kannst.
Also etwa:
1
for(;Unconditional{};){
2
3
}
Könnte man natürlich (in C++) machen. Oder in C eben mit for(;"ever";);
Wenn Du etwas weglässt, ist es eben nicht mehr explizit, sondern
implizit.
Rolf M. schrieb:> Wilhelm M. schrieb:>> iterate(Forever{})([]{>> r *= 2;>> });>> Was lisp kann (Klammernorgien), das bekommen wir in C++ doch auch locker> hin. ;-)
Während in Lisp hauptsächlich runde Klammern verwendet werden, kann man
in C++ alle Klammersymbole, die ASCII hergibt, also ()[]{}<>, fast nach
Belieben mischen.
Ich würde übrigens im obigen Lambda-Ausdruck die leere und deswegen
optionale Parameterliste explizit hinschreiben, weil sonst – ähnlich wie
bei der weggelassenen Bedingung in for(;;) – überhaupt nicht klar ist,
was der Compiler dafür einsetzt. Also so:
1
iterate(Forever{})([](){
2
// \___ ___/
3
// V
4
// 9, wow
Wilhelm schafft es sicher auch noch, das Beispiel mit ein paar
Template-Klammern (<>) aufzuhübschen, dann sind wir nicht mehr weit weg
von der Programmiersprache ], die zu einem würdigen Nachfolger von C++
werden könnte:
https://esolangs.org/wiki/Right_bracket
Wilhelm M. schrieb:> Wenn Du explizit das Fehlen von etwas hinschreiben möchtest,
Es fehlt doch aber nichts.
> dann brauchst Du dafür eben ein Konstrukt, was Du schreiben kannst.
Warum sollte ich was hinschreiben müssen, um damit auszudrücken, dass es
eigentlich nichts zum hinschreiben gibt?
C11/No Standard Library
Autosar19:
note 9177: condition of 'while' statement has non-Boolean type 'int'
[AUTOSAR Rule A5-0-2]
info 716: infinite loop via while
MISRA C 2012:
note 9036: essential type of condition of 'while' statement is 'signed8'
but should be boolean [MISRA 2012 Rule 14.4, required]
info 716: infinite loop via while
Die Info 716 wird immer getriggert, also nach MISRA und Autosar ist
while(1) praktisch doppelt böse. :-)
BARR-C 2018 hatte ich ja schon erwähnt.
Im SEI CERT C Coding Standard habe ich spontan nichts gefunden, also im
Netz, die Präferenz scheint da aber bei while(true) zu liegen.
1
#include <stdbool.h>
2
3
int main(void)
4
{
5
while (true)
6
{
7
}
8
}
MISRA C 2012:
info 716: infinite loop via while
supplemental 893: expanded from macro 'true' (line 17)
Interessant fände ich jetzt noch andere Beispiel von Coding Guidelines.
Ich habe gerade die ISO/IEC 17961 gefunden, bzw. natürlich nur den
Hinweis und nicht den Standard selber.
https://www.iso.org/standard/61134.html
Rudolph R. schrieb:> Interessant fände ich jetzt noch andere Beispiel von Coding Guidelines.
Ich bin erschüttert. Richtige Betriebssysteme brauchen Endlosschleifen,
aber die NASA nicht.
1
C Style and Coding Standards for SunOS
2
Bill Shannon
3
Copyright 1993 by Sun Microsystems, Inc.
4
5
for statements
6
for (initialization; condition; update) { statements; }
7
When using the comma operator in the initialization or update clauses
8
of a for statement, it is suggested that no more than three variables
9
should be updated. More than this tends to make the expression too
10
complex. In this case it is generally better to use separate
11
statements outside the for loop (for the initialization clause),
12
or at the end of the loop (for the update clause).
13
14
The infinite loop is written using a for loop.
15
for (;;) { statements; }
1
/*
2
* The NetBSD source code style guide.
3
* (Previously known as KNF - Kernel Normal Form).
4
*
5
* from: @(#)style 1.12 (Berkeley) 3/18/94
6
*/
7
/* Forever loops are done with for's, not while's. */
1
C STYLE GUIDE, AUGUST 1994
2
SOFTWARE ENGINEERING LABORATORY SERIES SEL-94-003
3
National Aeronautics and Space Administration
4
Goddard Space Flight Center
5
Greenbelt, Maryland 20771
Dieses 100-Seiten Werk erwähnt solche Schleifen mit keiner Silbe.
Edit: linux-source-4.19/Documentation/process/coding-style.rst schreibt
auch nichts vor.
Yalu X. schrieb:> Während in Lisp hauptsächlich runde Klammern verwendet werden, kann man> in C++ alle Klammersymbole, die ASCII hergibt, also ()[]{}<>, fast nach> Belieben mischen.
Das geht in C auch ;-) Allerdings ist in C die Wahrscheinlichkeit, dass
sich dadurch ein valides C Programm ergibt, geringer.
> Ich würde übrigens im obigen Lambda-Ausdruck die leere und deswegen> optionale Parameterliste explizit hinschreiben, weil sonst – ähnlich wie> bei der weggelassenen Bedingung in for(;;) – überhaupt nicht klar ist,> was der Compiler dafür einsetzt.
Leider falsch.
Wenn Du in for(;true;) oder for(;false;) den Boole'schen Wert weglässt,
wird dafür (in C) ein implementation-defined Wert != 0 eingesetzt.
Wenn Du in dem Lambda-Ausdruck [](){} die leere Parameterliste weglässt,
wird die durch nichts, auch nichts anderes ersetzt.
Also so:
> iterate(Forever{})([](){> // \___ ___/> // V> // 9, wow>> Wilhelm schafft es sicher auch noch, das Beispiel mit ein paar> Template-Klammern (<>) aufzuhübschen,
Hatte ich doch schon, oder?
Bauform B. schrieb:> Rudolph R. schrieb:>> Interessant fände ich jetzt noch andere Beispiel von Coding Guidelines.>> Ich bin erschüttert. Richtige Betriebssysteme brauchen Endlosschleifen,> aber die NASA nicht.
Naja es gibt halt neben "richtigen" Betriebssystemen auch
Betriebssysteme die im Space steuerbar sein müßen. Da sind
Endlosschleifen das letzte was man will, siehe bspw. WatchDogtimer.
DSGV-Violator schrieb:> Naja es gibt halt neben "richtigen" Betriebssystemen auch> Betriebssysteme die im Space steuerbar sein müßen. Da sind> Endlosschleifen das letzte was man will, siehe bspw. WatchDogtimer.
Nun, wenn es ein Task ist, welcher die lebenserhaltenden Systeme steuert
und überwacht … also ich hätte da schon gerne eine Endlos-Schleife. ;-)
Norbert schrieb:> Nun, wenn es ein Task ist, welcher die lebenserhaltenden Systeme steuert> und überwacht … also ich hätte da schon gerne eine Endlos-Schleife. ;-)
Ich denke auch, dass es eher unschön ist, wenn beim Wiedereintritt die
Raketensteuerung aussetzt, weil sich das Programm beendet hat.
Wilhelm M. schrieb:> Wenn Du in dem Lambda-Ausdruck [](){} die leere Parameterliste weglässt,> wird die durch nichts, auch nichts anderes ersetzt.
Na sicher wird sie das - durch eine leere Parameterliste. Das steht so
im C++-Standard: "If a lambda-expression does not include a
lambda-declarator, it is as if the lambda-declarator were ()."
Also darfst du sie deiner eigenen Logik folgend nie weglassen.
Wilhelm M. schrieb:> Yalu X. schrieb:>> Ich würde übrigens im obigen Lambda-Ausdruck die leere und deswegen>> optionale Parameterliste explizit hinschreiben, weil sonst – ähnlich wie>> bei der weggelassenen Bedingung in for(;;) – überhaupt nicht klar ist,>> was der Compiler dafür einsetzt.>> Leider falsch.> Wenn Du in for(;true;) oder for(;false;) den Boole'schen Wert weglässt,> wird dafür (in C) ein implementation-defined Wert != 0 eingesetzt.>> Wenn Du in dem Lambda-Ausdruck [](){} die leere Parameterliste weglässt,> wird die durch nichts, auch nichts anderes ersetzt.
Nix falsch (Rolf hat dich auf deinen Trugschluss bereits hingewiesen).
Weil dir keine echten Argumente mehr einfallen, begibst dich gerade auf
das Niveau der reinen Wortklauberei. Lass es mich dir noch etwas
ausführlicher erklären, als es Rolf bereits getan hat:
Natürlich hast du insofern recht, dass bei der Spezifikation des
for-Statements im C-Standard das Wort "replaced" auftaucht:
"An omitted expression-2 is replaced by a nonzero constant."
In der Spezifikation der Lambda-Expression im C++-Standard wird der
entsprechende Sachverhalt mit "as if" formuliert:
"If a lambda-expression does not include a lambda-declarator, it is as
if the lambda-declarator were ()."
Da auch beim for-Statement die as-if-Regel gilt, kann der obige Satz
ohne die geringste Änderung seiner Aussage wie folgt umformuliert
werden:
"If a for statement does not include expression-2, it is as if
expression-2 is a nonzero constant."
Uns siehe da, das "replaced", an dem du dich so festkrallst, ist weg,
und die fehlenden expression-2 wird einfach durch nichts ersetzt.
Genauso gut kann der Satz mit dem lambda-declarator ohne die geringste
Änderung seiner Aussage wie folgt formuliert werden:
"An omitted lambda-declarator is replaced by ()."
Jetzt steht auch hier ein "replaced". Die fehlende Parameterliste wird
also durch die leere Parameterliste (ein einfaches Klammerpaar) ersetzt.
Wer also darauf besteht, im Kopf einer Endlosschleife die Bedingung
"true" hinzuschreiben, der sollte konsequenterweise bei parameterlosen
Lambda-Ausdrücken die leere Parameterliste hinschreiben. Wenn du das
partout ablehnst, hat es wenig Sinn, mit dir weiter über Logik in der
Programmierung zu diskutieren.
Yalu X. schrieb:> Wer also darauf besteht, im Kopf einer Endlosschleife die Bedingung> "true" hinzuschreiben,
Ich bestehe nicht darauf und habe nicht darauf bestanden: ich habe nur
gesagt, dass for(;;) weniger explizit als while(true) ist. Und da Rolf
M. nicht weiß, was explizit ist, habe ich geschrieben, dass for(;true;)
explizit ist, nur um ihm und Dir das klar zu machen. Ich habe nicht
darauf bestanden, ein true hinzuschreiben.
> der sollte konsequenterweise bei parameterlosen> Lambda-Ausdrücken die leere Parameterliste hinschreiben.
Nein, beides hat gar nichts miteinander zu tun. Es sind konzeptionell
unterschiedliche Dinge, die dort passieren.
Das eine ist der Ersatz für einen nicht-vorhandenen Ausdruck, und ein
Ausdruck liefert einen Wert. Und das andere ist die Möglichkeit, eine
leere Parameterliste auszudrücken, also kein Ausdruck und damit kein
Wert. Man kann sich nur darüber unterhalten, ob eine leere
Parameterliste (leere Menge) oder eine nicht-vorhandene Parameterliste
(nicht existierende Menge) gleich ist. Da in beiden Fällen kein
Statement des Blocks des L-Ausdrucks etwas der leeren Menge oder der
nicht-existierenden Menge referenzieren kann, ist beides aber
konzeptionell identisch. Es findet auch kein Ersatz durch irgendeinen
Standardwert statt.
> Wenn du das> partout ablehnst,
Ich habe das nicht abgelehnt, auch nicht überall.
Du hast das ins Spiel gebracht.
> hat es wenig Sinn, mit dir weiter über Logik in der> Programmierung zu diskutieren.
Die Texte im C++-Standard sind übrigens (falsch von Dir wiedergegeben,
Du hast C und C++ Standard vermengt):
1
The for statement
2
for ( init-statement conditionopt ; expressionopt ) statement
3
is equivalent to
4
{
5
init-statement
6
while ( condition ) {
7
statement
8
expression ;
9
}
10
}
und
1
Either or both of the condition and the expression can be omitted. A missing condition makes the implied
Wilhelm M. schrieb:> Man kann sich nur darüber unterhalten, ob eine leere Parameterliste> (leere Menge) oder eine nicht-vorhandene Parameterliste (nicht> existierende Menge) gleich ist.
Natürlich sind das zwei verschiedene Dinge, da muss man sich nicht lange
darüber unterhalten. Allerdings wird in Lambda-Ausdrücken eine nicht
vorhandene Parameterliste gleich behandelt wie eine leere. Ebenso wird
eine nicht vorhandene Bedingung in einer for-Anweisung gleich behandelt
wie eine immer erfüllte.
Ob das optionale Ding ein Ausdruck oder eine Parameterliste ist, macht
meiner Meinung nach für Diskussion, die wir hier führen, keinen
Unterschied. Für beide gilt: Entweder man schreibt es explizit hin, oder
man lässt es weg, dann wird es implizit festgelegt.
Wilhelm M. schrieb:> Die Texte im C++-Standard sind übrigens (falsch von Dir wiedergegeben,> Du hast C und C++ Standard vermengt):
Das Thread-Thema ist for(;;) in C:
Jan S. schrieb:> for(;;){} Schleife> Guten Tag,> habe diese Schleife in einer älteren C-Firmware von Pic-Microchip> gesehen
Deswegen habe ich dafür den C-Standard herangezogen.
Die Lambda-Ausdrücke, die du ins Spiel gebracht hast, gibt es aber nur
in C++, deswegen habe ich dort den C++-Standard zitiert.
Ich hätte natürlich auch für for(;;) den C++-Standard zitieren können.
Da sich dort der entsprechende Satz vom C-Standard nur in der
Formulierung, nicht aber in seiner Aussage unterscheidet, hätte dies an
meiner Argumentation nichts geändert.
Roland F. schrieb:> Wilhelm M. schrieb:>> for ( init-statement conditionopt ; expressionopt ) statement>> Da fehlt was.
Falls du das Semikolon meinst: Das ist bereits im init-statement
enthalten.
Wilhelm M. schrieb:> Man kann sich nur darüber unterhalten, ob eine leere> Parameterliste (leere Menge) oder eine nicht-vorhandene Parameterliste> (nicht existierende Menge) gleich ist.
Natürlich sind sie unterschiedlich. Eine Funktion braucht immer eine
Parameterliste. Diese kann leer sein. Im Falle von Lambdas (und nur
dort) hat man eben entschieden, dass sie nicht angegeben werden muss und
dass das exakt so behandelt wird, als hättest du eine leere
Parameterliste angegeben. Genau das sagt doch auch der von mir zitierte
Satz aus dem Standard.
Übrigens würde ich eigentlich erwarten, dass du nicht nur () schreibst,
sondern "explizit" hinschreibst, dass die Parameterliste leer sein soll,
also (void). Wenn du das weglässt, ist sie ja nur noch implizit leer,
und explizit ist doch immer besser als implizit.
> Da in beiden Fällen kein> Statement des Blocks des L-Ausdrucks etwas der leeren Menge oder der> nicht-existierenden Menge referenzieren kann, ist beides aber> konzeptionell identisch. Es findet auch kein Ersatz durch irgendeinen> Standardwert statt.
Der Standardwert ist die leere Liste.
DSGV-Violator schrieb:> Und wenn sich ein Unterprogramm unerwartet beendet, kann es immer noch> von einem Master(-programm) neugestartet werden.
Und was, wenn sich mangels Endlosschleife das Master-Programm beendet
hat?
> Eine unendliche Schleife bedeudet nun mal kontrolleinschränkung/-verlust> für einen Supervisor.
Wenn es um Software im Sinne von manuell gestarteten Programmen geht und
seine Ausführung die Möglichkeit blockiert, andere Programme zu starten,
ja. Auf der anderen Seite stehen µC-Anwendungen, bei denen es essenziell
ist, dass das Programm als Endlosschleife läuft, denn wenn es sich
beenden sollte, passiert je nach dem entweder irgendein Blödsinn, der
Watchdog macht einen Reset des Systems, oder der µC läuft in eine leere
Fallback-Endlosschleife. In der Regel will man keins davon.
Das gleich gilt letztendlich auch für dein Master-Programm /
Betriebssystem.
> Der Standardwert ist die leere Liste.
Liste ist ein Datentyp, aber keine Anweisung/Conbtrol-Struktur. C kennt
im Standard keine Liste, höchstens pointer, bitfields und structs als
komplexere datentypen.
https://de.wikipedia.org/wiki/Liste_(Datenstruktur)
DSGV-Violator schrieb:>> Der Standardwert ist die leere Liste.>> Liste ist ein Datentyp, aber keine Anweisung/Conbtrol-Struktur. C kennt> im Standard keine Liste, höchstens pointer, bitfields und structs als> komplexere datentypen.
Du bist genauso ein Wortklauber wie der Wilhelm. Es dürfte doch aus dem
Kontext mehr als klar hervorgehen, dass mit "Liste" die Parameterliste
gemeint ist.
DSGV-Violator schrieb:> Wilhelm M. schrieb:>> DSGV-Violator schrieb:>>> Naja, das Dumme ist, das Standard-C in der Praxis keine boolean Werte>>> wie 'true' kennt.>>>> Mindestens seit C99 aber schon.>> Nö. Es gibt da schon einen Unterschied zwischen Sprache und> Standardbibliotheken.
Doch. In stdbool.h gibt es bool, ist als der Typ _Bool definiert. Man
kann _Bool natürlich auch direkt verwenden.
Seit C23 sind true, false und bool keywords, das heisst man braucht
stdbool.h und auch _Bool nicht mehr.
bool hat einige interessante Eigenschaften.
1
_Boolb=0;
2
b++;// Ergebnis der Expression ist 0 zurück, enthält nachher 1
3
b++;// Ergebnis der Expression ist 1, b enthält nachher immer noch 1
4
b=10;// b enthält nachher 1
5
b--;// Ergebnis der Expression ist 1, b enthält nachher 0
6
b--;// Ergebnis der Expression ist 0, b enthält nachher 1
7
b--;// Ergebnis der Expression ist 1, b enthält nachher 0
Und ja, auch ein Wert vom typ (_Bool){1} gibt es, also ein echtes true,
das sind nicht simple ints:
DSGV-Violator schrieb:>> Der Standardwert ist die leere Liste.>> Liste ist ein Datentyp, aber keine Anweisung/Conbtrol-Struktur. C kennt> im Standard keine Liste, höchstens pointer, bitfields und structs als> komplexere datentypen.
Es ging nicht um Datentypen, sondern um Parameterlisten. Und die sind
selbstverständlich im C-Standard definiert:
********************************
parameter
formal parameter
formal argument (deprecated)
object declared as part of a function declaration or definition that
acquires a value on entry to the function, or an identifier from the
comma-separated list bounded by the parentheses immediately following
the macro name in a function-like macro definition
********************************
> Wenn es um Software im Sinne von manuell gestarteten Programmen geht und> seine Ausführung die Möglichkeit blockiert, andere Programme zu starten,> ja. Auf der anderen Seite stehen µC-Anwendungen, bei denen es essenziell> ist, dass das Programm als Endlosschleife läuft, denn wenn es sich> beenden sollte, passiert je nach dem entweder irgendein Blödsinn, der> Watchdog macht einen Reset des Systems, oder der µC läuft in eine leere> Fallback-Endlosschleife. In der Regel will man keins davon.
In Sicherheitskritischen Anwendungen wie Space/Avionic will man aber
eine "last resort" Signal-Möglichkeit um das System schnell und mit
definierte Latenz in einem "Safe harbour" Zustand zu bringen. Oder eben
Reboot.
Und natürlich macht nur ein von einem Blödian designtes System
"Blödsinn" nach Beendigung einer Schleife. Ein von einem Kompetenten
Systemdesigner designtes System geht mach programmabarbeitung in einen
definierten Zsutand ("Power-Down, Hibernate, ...). Falls die Mittel der
Software dazu nicht ausreichen muß eben die Hardwareabteilung
entsprechende Abschaltungen (Tri-State, gemeinsames Potential, inert
state) vorsehen.
Aber wie schon das wording "System" hinweist, geht eine solche
Betrachtung weit über den Horizont eines niedrig-hierarchischen
Endlos-C-Schleifen-Programmieres hinaus.
Die NASA hat eben ihren guten Gründe auf in irdischen Massstäben übliche
Programmierweise zu verzichten respektive als bekannt unsicher zu
verbieten.
> Es ging nicht um Datentypen, sondern um Parameterlisten. Und die sind> selbstverständlich im C-Standard definiert:> ********************************> parameter> formal parameter> formal argument (deprecated)> object declared as part of a function declaration or definition that> acquires a value on entry to the function, or an identifier from the> comma-separated list bounded by the parentheses immediately following> the macro name in a function-like macro definition> ********************************
Also das hinter dem 'for' in Klammern heisst jetzt "Parameterliste" wie
bei einem Funktionsaufruf??
Das sind aber nun mal aber im syntax-Sinne keine Parameter sondern
Anweisungen. Deshalb finden sie sich auch im Code- und nicht im
Data-segment.
Jetzt haben die Väter von C explizit eine kurze und konsistente
Endlosschleife realisiert und favorisiert ohne andere Konstrukte
einzuschränken ... und hier wird ernsthaft argumentiert, das nicht zu
nutzen.
Ein Anfänger weiß nicht, dass i++ äquivalent ist zu i=i+1. Der Code wird
aber nicht besser, wenn man auf ++ verzichtet.
Bruno V. schrieb:> und hier wird ernsthaft argumentiert, das nicht zu nutzen.
Ich sehe diese Diskussion auch als nutzlos an. Man kann in C eine
Endlosschleife auf verschiedene Art und Weise produzieren... na und?
Wenn verschiedene Arten angeboten werden, dann kann man die auch nutzen.
Ob die eine oder andere "besser" ist, spielt überhaupt keine Rolle. Der
Compiler erzeugt da ganz emotionslos denselben Code.
Deshalb verstehe ich diesen ganzen Hickhack um Begriffe hier auch nicht.
Der eine oder andere hier mag sich bitte mal besinnen und sich fragen,
ob diese kleinkarierte Diskussion überhaupt der Mühe wert ist.
Bruno V. schrieb:> Jetzt haben die Väter von C explizit eine kurze und konsistente> Endlosschleife realisiert und favorisiert ohne andere Konstrukte> einzuschränken ... und hier wird ernsthaft argumentiert, das nicht zu> nutzen.
Weder konsistent noch favourisiert und "kurz" ist bezüglich der
Forderung nach verständlichen Code auch mehr von Nach- als Vorteil.
Werdet doch endlich mal erwachsen und insestiert nicht, wie es damals
die "Väter" in Ihre Tontafel ritzten, sondern wie es Euch und Eurer Zeit
nutzt. Man läuft doch auch nicht mehr in den gleichen Klamotten wie die
Väter damals ...
Echt, manche haben hier im Forum weniger Selbstbewusstsein, Pragmatismus
und Autonomiestreben als die Aimish oder ein Haufen Schläfenbelockter
Talmud-Schüler. SCNR
https://youtu.be/pc04f4w17rM?t=290https://de.wikipedia.org/wiki/Pragmatismus
Aber eigentlich muss man ja nicht sofort zu einem einstimmigen Fazit
kommen, manchmal genügt es festzustellen, das manche reifer sind als
andere aber noch nicht alles Wasser den Nil abwärts geflossen ist ...
> Wenn verschiedene Arten angeboten werden, dann kann man die auch nutzen.
Eben, goto ist hier das beste Angebot um eine eine unbedingte Schleife
zu schliessen. Aber Goto ist ja böse - hat 'Papa' gesagt.
DSGV-Violator schrieb:> Werdet doch endlich mal erwachsen und fragt nicht wie es damals die> "Väter" in Ihre Tontafel ritzten, sondern wie es Euch und Eurer Zeit> nutzt.
Auch wenn ich Dir in diesem Thread fast nirgends zustimme, so ist das
genau das, was ich hier
Beitrag "Re: for(;;){} Schleife"
schonmal als "katholisch" bezeichnet hatte.
Demnächst wird noch gefordert, dass man doch besser zu den "halben"
Funktionsprototypen im K&R-Stil zurückkehren sollte.
Wilhelm M. schrieb:> Demnächst wird noch gefordert, dass man doch besser zu den "halben"> Funktionsprototypen im K&R-Stil zurückkehren sollte.
Ich fordere die komplette Abkehr von dieser kaputten Sprache.
Das war noch vor meiner Zeit. Es gibt aber durchaus Situationen, in
denen ich die alte Schreibweise noch hätte gebrauchen können, wenn es
sie noch gäbe.
1
// OK:
2
voidmyfunction(intw,inth,intx[h][w]){}
3
4
// Fehler
5
voidmyfunction2(intx[h][w],intw,inth){}
6
7
// Fehler, Schreibweise leider nicht mehr erlaubt:
MaWin O. schrieb:> Ich fordere die komplette Abkehr von dieser kaputten Sprache.
Das kannst du sehr professionell bewerkstelligen:
Stecke einfach den Kopf in den Sand.
Es gibt ja auch ›gute‹ Programmiersprachen für den Vogel Strauß,
›Scratch‹ fiele mir da ein, oder ›Turtle-Graphics‹
DSGV-Violator schrieb:> Also das hinter dem 'for' in Klammern heisst jetzt "Parameterliste" wie> bei einem Funktionsaufruf??
Nein, wie kommst du denn darauf?
> Das sind aber nun mal aber im syntax-Sinne keine Parameter sondern> Anweisungen. Deshalb finden sie sich auch im Code- und nicht im> Data-segment.
In C gibt es kein Code- oder Data-Segment. Abgesehen davon hat das auch
rein gar nichts mit Parameterlisten zu tun.
DSGV-Violator schrieb:> Werdet doch endlich mal erwachsen und insestiert nicht, wie es damals> die "Väter" in Ihre Tontafel ritzten, sondern wie es Euch und Eurer Zeit> nutzt. Man läuft doch auch nicht mehr in den gleichen Klamotten wie die> Väter damals ...
Ich habe das nicht nach den "Vätern" gemacht. Ich wusste nicht einmal,
dass das im K&R so steht, bevor es hier jemand zitiert hat. Ich habe
selbst für mich entschieden, dass ich diese Form für Endlosschleifen
bevorzuge, und zwar primär, weil ich die eigentlich unnütze Bedingung
nicht angeben muss. Das macht es für mich einfach zur natürlicheren Wahl
für eine unbedingte Schleife. Ich war dann aber doch sehr erstaunt, als
Wilhelm das als "an den Haaren herbeigezogen" betitelt hat.
>> Wenn verschiedene Arten angeboten werden, dann kann man die auch nutzen.>> Eben, goto ist hier das beste Angebot um eine eine unbedingte Schleife> zu schliessen. Aber Goto ist ja böse - hat 'Papa' gesagt.
Für Endlosschleifen ist es auch nicht wirklich sinnvoll. Es gibt aber
sinnvolle Anwendungsfälle von goto, und dort verwende ich es dann auch.
> In C gibt es kein Code- oder Data-Segment. Abgesehen davon, hat das auch> rein gar nichts mit Parameterlisten zu tun.
Doch hat es, Parameter sind Daten und Zuweisungen sind Instruktionen.
> Ich habe> selbst für mich entschieden, dass ich diese Form für Endlosschleifen> bevorzuge,
Neee wie Du das für Dich entscheidest interessiert kein Schwein und kein
Compiler. Du hast hier garnichts "selbst" zu entscheiden, du hast (wie
jeder andere auch) korrekten und möglichst verständlichen Syntax zu
schreiben. Und für viele ist eben eine Ausage wie etwas nicht ist (Eine
unendliche Schleife ist wie eine Schleife ohne Parametreliste) nicht
sonderlich erklärend.
Im Hitchhiker und anderer Belletristik finden sich solche
Gedankenmuster, die etwas über ihre Nicht-Sein erklären wollen, bspw.:
"Fliegen heißt Lernen sich auf den Boden zu schmeißen und ihn zu
verfehlen. Flying is learning how to throw yourself at the ground and
miss."
> Für Endlosschleifen ist es auch nicht wirklich sinnvoll.
Doch gerade bei Endloschleifen ist das sinnvoll. Weil ja der Sinn (und
das Compilat) hinter einer "Endlosschleife" der unbedingte Sprung ist.
Und welches Schlüsselwort hat C für "unbedingten Sprung" vorgesehen?
Eben, "Goto" .
DSGV-Violator schrieb:>> In C gibt es kein Code- oder Data-Segment. Abgesehen davon, hat das auch>> rein gar nichts mit Parameterlisten zu tun.>> Doch hat es, Parameter sind Daten und Zuweisungen sind Instruktionen.
Parameter landen aber in der Regel in Registern oder auf dem Stack, und
das true in der Schleifenbedingung ist keine Zuweisung, sondern ein
Ausdruck, der vom Compiler üblicherweise komplett wegoptimiert wird,
also nachher meist gar nirgends landet. Das ist aber alles wie gesagt in
C nicht spezifiziert, sondern komplett vom Compiler abhängig und damit
in diesem Zusammenhang irrelevant.
>> Ich habe>> selbst für mich entschieden, dass ich diese Form für Endlosschleifen>> bevorzuge,>> Neee wie Du das für Dich entscheidest interessiert kein Schwein und kein> Compiler.
Dass es dem Compiler egal ist, haben wir vor langem bereits
festgestellt. Und ob es ein "Schwein" interessiert ist mir egal, denn
für die schreibe ich den Code nicht. Ich schreibe ihn abgesehen vom
Compiler für Programmierer, die der Sprache zumindest auf einem gewissen
Grundniveau mächtig sind. Wer nicht mal weiß, wie eine for-Schleife
funktioniert, soll lieber die Finger davon lassen, bis er es gelernt
hat.
> Du hast hier garnichts "selbst" zu entscheiden, du hast (wie> jeder andere auch) korrekten und möglichst verständlichen Syntax zu> schreiben.
Ich kann sehr wohl entscheiden, wie ich meinen Code schreibe, denn du
bist nicht die Codepolizei, die mir das verbieten könnte. Und ja, ich
habe mich dazu entschieden ihn korrekt und möglichst verständlich zu
schreiben.
for (;;) ist weder inkorrekt, noch unverständlich.
> Und für viele ist eben eine Ausage wie etwas nicht ist (Eine> unendliche Schleife ist wie eine Schleife ohne Parametreliste) nicht> sonderlich erklärend.
Das ist wie bei den meisten Stilfragen und wie auch hier schon öfter
angemerkt wurde, etwas subjektives. Ich finde es klar, lesbar und
einleuchtend. Das magst du anders sehen, aber das ist dann eben deine
persönliche Sichtweise, sprich: Du hast für dich entschieden, dass du
eine andere Schreibweise bevorzugst - oder jemand anders hat das für
dich entschieden, und du folgst dem nur dogmatisch. Mehr Optionen gibt's
da nicht.
>> Für Endlosschleifen ist es auch nicht wirklich sinnvoll.> Doch gerade bei Endloschleifen ist das sinnvoll. Weil ja der Sinn (und> das Compilat) hinter einer "Endlosschleife" der unbedingte Sprung ist.> Und welches Schlüsselwort hat C für "unbedingten Sprung" vorgesehen?> Eben, "Goto" .
Mit der Argumentation kannst du alle Schleifen per goto umsetzen, denn
mit einem if kannst du dem ja auch eine Bedingung hinzufügen.
Aber eine Schleife wird in C nunmal üblicherweise mit for oder
(do/)while und einem Codeblock geschrieben. Warum sollte ich davon bei
einer Endlosschleife abweichen? Das wäre tatsächlich unintuitiv. Ich
würde aus Gründen der Lesbarkeit generell davon abraten, goto für
Rückwärtssprünge zu verwenden.
Announcement: there is an English version of this forum on 
