|
Anzeige
|
for(;;){} SchleifeGuten 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?
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
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!
edit: Bonus: for(;;) spart 1 Zeichen! ☺️☺️ Gruss Jan
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 im Beitrag #7474436:
Im Buch "Code complete" von Steve McConnell wird für C empfohlen eine Endlosschleife mit einem Makro einzuleiten:
rhf
Dann solltest Du das Buch wegwerfen ;-) @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 Hallo, Wilhelm M. schrieb im Beitrag #7474468:
Warum? rhf Vorteil gedruckter Bücher: Man kann sie besonders in diesem fall sehr einfach patchen. ;-)
Was soll der Compiler denn warnen, wenn das Macro zu 1 oder true ersetzt wird? Hallo, Harald K. schrieb im Beitrag #7474495:
Au, nicht aufgepasst beim abschreiben, richtig also:
rhf
"condition is always true" oder sowas. Zumindest irgendwelche lint müssen sowas moniert haben.
Gast
#7474548
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-c https://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"
Auf den ersten Blick ein schöner Hack, allerdings wird
leider nicht den gewünschten Effekt haben. Von daher ist der Hack dann doch eher hässlich ;-)
Beitrag #7474667 wurde von einem Moderator gelöscht.
War auch nicht die Intention. Jedes Stringarray steht an einer Adresse != 0. Der Inhalt des Strings ist also immer egal.
Gast
#7474741
+1
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.
Das ist doch an den Haaren herbei geholt!
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.
"while forever" ("während für immer") sagt kein Mensch, nicht einmal ein Engländer aus gehobenen Kreisen. Deswegen etwas besser:
Aber wie die meisten Vorposter würde ich des "ever" einfach weglassen :)
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.
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(;;).
Ja, wenn man ein Sprachelement nicht kennt, muss man "nachdenken", bzw. es eben lernen.
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.
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...
Man könnte es auch noch
nennen. :-)
Qt definiert tatsächlich so ein Makro: https://doc.qt.io/qt-5/qtglobal.html#forever
Natürlich gibt es Bedingungen, die immer wahr sind.
Dann mach das doch auch in C.
Sehr richtig.
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.
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.
Hä? Das mache ich doch. Das war doch genau der Punkt. Dazu brauche ich aber for, weil das mit while nicht geht.
Also ich finde "Schleife: …" eher explizit für eine Endlosschleife als "Schleife, solange wahr wahr ist: …".
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.
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.
Nö, warum? Wie der Compiler das umsetzt, ist mir eigentlich egal. Das einzig Wahre ist eh nur die Rust-Endlosschleife.
Alles andere kann auf den Müllhaufen der Geschichte. Das ist die endgültige Antwort. Ah, du meinst also
schon ist man Rust-kompatibel. :-))) Na, dann würde ich mal
und
in den Ring werfen.
Ersetze explizit mit kryptisch, dann passt es. Oder in deiner Sprache: 's/explizit/kryptisch/'
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.
Dann doch lieber
scnr 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.
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?
In der 10 Jahre jüngeren 2. Auflage steht das immer noch so :)
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
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 ;-) Ich habe auch schon mal while(42) { } hin geschrieben. :-) Ansonsten hat aber Jörg da ganz weit oben das schon gut begründet, hier noch ein Link dazu als Beispiel für Coding Guidelines:
Gast
#7475927
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 ;-)
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 ;-)
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).
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.
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? Grundsätzlich sind in C/C++ Endlos-Schleifen, die /keine/ Seiteneffekte enthalten, UB und können deswegen entfernt werden.
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. Endlosschleifen wurden schon oft diskutiert. Auch auf Stackoverflow. Z.B https://stackoverflow.com/questions/20186809/endless-loop-in-c-c Ich halte es für viel wichtiger es gut zu kommentieren als über die Form zu philosophieren.
Sie können entfernt werden, ja. Aber, dass sie UB sind, würde ich mal stark bezweifeln. Wo steht das?
Das bedeutet, dass eine Endlos-Schleife ohne Seiteneffekt kein valides C++ Programm ist. Und das bedeutet, dass es UB ist.
Da steht aber nichts von UB. Ganz im Gegenteil.
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?
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.
Und was startet die Threads? 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.
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.
"In a valid C++ program, every thread" "The implementation may assume that any thread" 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.
Gast
#7476048
beides ist eine Implementierung von reaktionsbereiten Dauerlauf.
Och, zum Verlassen eine Endlosrn Schleifen gibt es noch weitere Möglichkeiten wie break oder goto.
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.
Nö, nicht im Embedded insbesonders beim Batteriebetrieb. Da ist Sleep der an häufigsten angenommen Betriebszustand. Sleep- und PowerDown ist nicht unbedingt dasselbe.
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.
Gast
#7476194
Grad mal im Parser in der Backus.Nauer-Form nachgeschaut.
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ß.
Leider vollkommen am Thema hier vorbei: es geht um keine Kodier-Richtinie.
Warum sollte die Frage, welches lateinische Wort das am besten passende wäre, für die Diskussion relevant sein? Hallo,
Genau, und es geht auch nicht um UB in C++. rhf
Schau nochmal auf welchen Beitrag ich das geschrieben hatte. Und wenn du magst streiche das ++.
Gast
#7476313
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_Spiralen https://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 :)
Schleife macht man am Schuh.
Was Du meinst, ist einfache eine Wiederholung.
Im Portable C Compiler wurde dieser Sprachstreit offenbar bereits antizipiert, denn dessen Yacc-Definition der Grammatik kommt völlig ohne dieses schreckliche Problem aus. ;-) https://github.com/IanHarvey/pcc/blob/master/cc/ccom/cgram.y
Man sollte also vorsichtshalber weder while(true) noch for(;;) verwenden, 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?
Nicht nötig. Ziemlich viel coffee to go wird gefahren. Hallo, Yalu X. schrieb im Beitrag #7477003:
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. ;-)
Im originalen C&R hat "for(;;)" gegen "while(1)" deshalb gewonnen, weil's ein Zeichen weniger zu tippsen ist :-)
Das wussten wir (ok, vllt außer dem TO) doch schon alle vorher.
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.
Natürlich, was denn sonst?
Dann sieht's für while(true) ja ganz schlecht aus. 😉
Wann hat denn der gute Brian seinen Namen gewechselt? Vor lauter geistiger Onanie in diesem Thread ist er entsetzt weggerannt. 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
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. #define break Ahh, gerade fällt es mir wie Schuppen aus den Augen: mit goto wird ein break verhindert!
Geil, ab sofort nutz ich nur noch goto! :-)
Bisher hab ich nur endliche Schleifen erzeugt. Wie würde man eine endlose Schleife erzeugen?
Das war übrigends ironisch gemeint.... :-)
Kannst Du die beiden wesentlichen Elemente benennen, die ich in dem Beispiel benutzt habe? Dann weißt Du auch die Lösung ;-)
Gast
#7477087
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 ;-)
Was meinst Du? Du nutzt ein Template und als Parameter eine Lambda Expression.
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?
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 { ... } Wilhelm M. schrieb:
OK, du meinst vermutlich ein Konstrukt ala
Aber eine Endlosschleife muss trotzdem erstellt werden. Ohne sehe ich keine Lösung.
Genau. Da aber das "break" im Closure stehen würde, wäre es syntaktisch falsch.
Naja, in dem Funktionstemplate kannst Du dann alles benutzen, was wir hier diskutiert haben, auch Dein goto ;-)
Ich hatte verschiedene Spezialisierungen in meinem Beispiel benutzt, damit kann man es noch etwas ausgestalten. Oder einfach:
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.
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.
Wer generische Lambda-Expressions verstanden hat, der hat C++ verstanden ;-)
Ich arbeite daran...
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.
Und nachdem der TO schon mit for(;;) Probleme hatte, glaubst du, dass er dieses hier
auf Anhieb versteht und sogar in der Lage ist, die dafür benötigte Template-Funktion selber zu schreiben? :-)
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. ... Mir gefällt und ich nutze "while(1) continue;" Wem muss ich hier um Erlaubnis fragen und bekomme ich jetzt Tadel oder Haue?
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.
Ich finde, du solltest da lieber auf Nummer sicher gehen und schreiben:
Aber was, wenn jemand 1 umdefiniert hat?
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. Mir schwirrt der Kopf über diesen wilden Tanz um des Kaisers Bart;-) Ich werde dickköpfig beim altbewährten for(;;); bleiben...
Du lebst scheinbar gefährlich... 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
oder
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 bedingungsLOS 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
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
:)
Das war dann im letzten Jahrtausend.
Bedingungslos 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.
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.
Und selbst das kann sinnvoll sein, wenn man eine Formel mit Wiedererkennungswert niederschreiben möchte. Pauschal ablehnen würde ich sowas nicht.
Bei Mikrocontrollern kann es viel Sinn ergeben, wenn man eine 0 um N Stellen nach links schiebt: ctrlreg = 1<<BITX | 0<<BITY.
Besser wäre allerdings
Das ist gewissermaßen der Gürtel zum Hosenträger.
Gast
#7478062
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
K&R wussten es damals nicht besser. :-) :-)
Den Fall, dass das goto nicht immer richtig funktioniert (Strahlen und so!) würde ich auf jeden Fall noch mit abfangen:
Die schaden bei sowas nur dem ohnehin schon vorverstrahlten Programmierer. Die Hardware sieht nur den Binärcode, und der ist der gleiche. ;-)
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.
Das hatte ich oben schonmal geschrieben.
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. Apropos Archäologie: Das hier erschien 4 Jahre vor K&R und beschreibt noch die alten Assign-Ops. Aber for(;;) ist schon ausdrücklich aufgeführt.
K&R erste Fassung von 1978. Wer das durchlas, konnte es kaum übersehen. Wer nicht, war selber Schuld.
Angehängte Dateien:
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…
Richtig:
Das Buch habe ich zuvor neu im Buchhandel erworben :)
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:
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:
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.
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 ;-)
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.
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.
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 ;-)
Ok, ich habe gerade eine Münze entscheiden lassen. Ergebnis: Kopf. Also meinst du das Gegenteil von dem, was du geschrieben hast ;-)
Möchtest du dafür gerne ein ›Let me google that for you‹ haben?
Wo wir schon so Top-seriös bei Sache sind: wenn dir das Geld für eigene Recherchen ausgegangen ist: Zahlungsverzug oder -Einstellung.
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.
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.
Nach dem Sermon, den Du dazu schreibst, bin ich mir da gerade nicht so sicher ...
Einer, der noch kein C-Buch durchgearbeitet hat, wird beim erstmaligen Anblick von
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.
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.
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?
Gast
#7478247
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.ä.
Wenn man sich länger als fünf Minuten mit C beschäftigt haben sollte, ist das keine Frage, die entsteht.
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.
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?
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.
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).
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; }
Und derjenige weiß dann, dass for(;;) einen impliziten Bedingungsteil hat, der immer true ist. Das glaubst Du doch selbst nicht.
Genau. Und das halte ich für ziemlich selbsterklärend.
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
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.
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.
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.
Ja, irgendwie muss der Thread doch seine Endlosschleife hier weiter fahren, oder? Hallo, so wird es sein. Der Endlos-Thread darf nie unterbrochen werden. :-)
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.
Intressant: ursprünglich stand dort also ein /while/, dass irgendjemand zu einem /for(;;)/ verschlimmbessert hat. Und das machte dann Deine Verständnisschwierigkeiten.
Gast
#7478404
.. 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.
Sehe ich auch so, hatte ich oben so geschrieben:
Ist das die arabische Version von /Amen/ ?
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?
Gast
#7478411
[offtopic]
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]
Danke, aber das es hebräisch ist, war mir schon klar.
Wikipedia kann ich selber lesen ;-) Und in deutsch wird es üblicherweise als "Amen" geschrieben.
Beitrag #7478413 wurde von einem Moderator gelöscht.
Keine Sorge, das kommt noch. Sprache pflegt sich den veränderten Gegebenheiten anzupassen. Aufgrund der obigen Diskussion muss ich natürlich noch den C++-Vorschlag von oben Beitrag "Re: for(;;){} Schleife" ändern.
oder
Das schreibe ich natürlich nur, um zu erfahren, wie die Formatierung von C++-Code geschieht, der auch Lambda-Expressions enthält.
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?
Der Leerlaufprozess kommt der aber ziemlich nahe. 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?
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?
Gast
#7478487
Nun, wenn es dir mit der bloßen Erwähnung der Onanie nicht getan ist, dann lies das Buch über Endlos geflochtene Bänder - in den Achtzigern schaffte es dieses sogar Wochenlang auf die Spiegel-Bestsellerliste: D. Hofstadter: "Gödel, Escher, Bach - ein Endlos Geflochtenes Band " Auch heute noch ein Klassiker, der auf keinem intellektuellem Kaffeekränzchen fehlen darf. https://www.booklooker.de/B%C3%BCcher/Douglas-R-HOFSTADTER+G%C3%B6del-Escher-Bach/id/A02wUkNe01ZZu https://www.heise.de/blog/Klassiker-neu-gelesen-Goedel-Escher-Bach-4702826.html
Das könnte man schon auch über einen Interrupt machen, dann wäre das Programm(oder "Betriebssystem") eine leere Endlosschleife.
Wieso sollte ich das ablehnen? Anscheinend hast Du immer noch gar nichts verstanden. Ein
wäre doch super. Ein
wäre doch auch prima. Nur ein
wieder Mist.
Gast
#7478515
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. 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
anstatt
Ich bin aber auch kein Profi. Hallo, Veit D. schrieb im Beitrag #7478344:
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:
ist äquivalent zu
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
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.
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
Wenn dann noch Label entsprechend benannt wird, weiß jeder sofort und unmissverständlich was gemeint ist Hallo, Wilhelm M. schrieb im Beitrag #7478416:
Warum? Wozu ist das gut, wo es doch hier um eine for(;;) in C geht? rhf
Ich fragte mich allerdings schon damals, wieviele derer, die es gekauft hatten, es auch in signifikantem Umfang gelesen hatten.
Gast
#7478533
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" ;-) Jetzt wollte ich es noch vom C30-Compiler von Microchip wissen:
Ernsthaft anders erwartet? Der ist ein Derivat des GCC.
Nein, aber es gibt Gewissheit...
Schon mal was von Funktionen gehört?
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:
Ach was, schon mal was von Schleifentransformation gehört?
Das ganz einfach an dieser dummen Praxis while(1) statt besser while(true) hinzuschreiben.
Es kann zum Glück auch auf den Misthaufen der Geschichte. In Rust kann das if-statement beides.
Gast
#7478616
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.
Klar, würde hier u.a. wegen Context-switch/Stack-Operationen das Problem noch vergrößern statt verkleinern.
Ja, C ist in vielerlei Hinsicht dumm! Siehe for(;;).
Hä???
Mindestens seit C99 aber schon. Um das hier mal abzukürzen: https://chat.openai.com/share/e7792666-daba-47ff-9c4c-797048b63da1 :)
Gast
#7478629
Nö. Es gibt da schon einen Unterschied zwischen Sprache und Standardbibliotheken. https://en.wikipedia.org/wiki/C_standard_library C++ ist da "fortschrittlicher". Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
