Moin ! Kurze Frage zu einer while schleife? Kann man so einen Vergleich ausführen? int size, x ; while(size == x) { ... x und size werden hier unterschiedlich erhöht, bis diese gleich sind } und danach soll die Schleife verlassen werden? Geht so was überhaupt?
Also theoretisch würd ich ja sagen; er steigt halt nur in die Schleife ein, solange size gleich x ist.
ahhh, da ist mein Fehler..Ich suche die Lösung, das er in die Schleife einsteigt und sie verläßt wenn die beiden Parameter gleich sind!
Na das mit dem Verlassen ist so ne Sache....du kannst es eben nur so programmieren, dass er in die Schleife einsteigt, wenn sie ungleich sind, und falls sie irgendwann gleich werden, steigt er eben erst gar nicht mehr in die Schleife ein.... Ich weiß nicht, ob das 'Rausspringen' so geht!! Bis jetzt hab ich while-Schleifen nur als Endlosschleifen gebraucht [also while(1)].
Wie von Miu geschrieben: 'Break' dannnn verlässt er die Schleife sofort oder mit 'continue' springt er wieder zum Schleifenanfang und prüft nochmal die Bedingung.
while( x==size){ //mach was } --> Abbruch bei x!=size while( x !=size){ //mach was } --> Abbruch bei x==size Alles klar? ;-) Gruß T.v.B.
break und continue sind zwar legitime C Anweisungen sollten aber wenn möglich nur in Ausnahmefällen benutzt werden. Da es in der Programmierung immer mehr als nur einen Lösungsweg gibt, sollte über eine Lösung ohne break bzw. continue nachgedacht werden. Es wäre "sauberer" und später besser wartbar, da ein plötzlicher Schleifenabbruch in einem komplexen System z.T. sehr schwer nachvollziehbar ist. Es stellt sich dann meist die Frage : WAS HAT SICH DER PROGRAMMIERER NUR DABEI GEDACHT ???? . Mein genereller RAT : Nur in Ausnahmefällen (kurze Testprogramme!!!) Quick and dirty programmieren ansonsten lieber ein wenig Zeit in die Programmstruktur investieren. Man wird spätestes beim Debuggen danken.
evtl. auch möglich je nachdem wann du die Überprüfung haben willst: do { //auszuführender Code } while(rest != x);
Tja, da unterscheiden sich unsere Erfahrungen. Bei Schleifen mit 3 Anweisungen im Schleifenkörper ist das sicher nicht der Rede wert. Aber bei größeren, komplexeren Bedingungen schon.
Dann schau Dir mal eine komplexe Software an, bei der aufgrund von Timing und anderer Dinge Prozesse aufgesplittet wurden und dieses mittels break und continue realisiert wurde. Dann wirst Du schnell feststellen das dies als Mittel zum Zweck geschah aber aber sehr schlecht wartbar/erweiterbar ist. Daher kommt kommt für mich nur das break in einer Switch/Case Struktur in Frage, alles andere ist erstmal Tabu, es gibt immer einen anderen Weg.
Ich würde mich Miu's Vorschlag anschliessen. Eine Fussgesteuerte Schleife ist genau, dass was gefragt ist, es wird in jedem fall einmal ausgeführt und danach getestet. Von wengen Break <-> While, ich will da nichts bewerten, beides hat seine Vor- und Nachteile aber wenn man schon mit Breaks arbeitet könnte man evtl. gleich ganz auf goto umsatteln, das hätte auch den grossen Vorteil das mit Sicherheit jeder Comiler aus einem goto ohne grosses Federlesen ein rjmp erzeugt, was natürlich schon performanter ist als denkbare Konstrukte die für ein while nötig sein dürften. Wobei ich auch nicht genau weiss was gcc aus while(1) macht. Nur so ein Gedanke. -wiebel
Ein guter Compiler erzeugt bei gleicher Semantik den gleichen Code. Da ist es egal, ob man while, do, oder break/continue/goto benutzt hat. Obwohl, beim GCC hätte ich da auch meine Zweifel.
Michael Waiblinger wrote: > Wobei ich auch > nicht genau weiss was gcc aus while(1) macht. Nur so ein Gedanke. Ernst gemeint? ;) -O0 (keine Optimierung):
1 | while(1) |
2 | ; |
3 | aa: ff cf rjmp .-2 ; 0xaa <main+0x1c> |
Hallo, Gast hat Recht, das Stichwort heißt "Strukturiertes Programmieren". Wichtig ist, dass ein Algorithmus mit einigen wenigen vernünftigen Kontrollstukturen auskommt, dazu gehören auch WHILE "Bedingung wahr" ... End While und REPEAT ... UNTIL Bedingung wahr (hier programmiersprachen-unabhängig formuliert, wie es bei der Entwicklung von Programmabläufen auch zunächst selbstverständlich ist.) Mehrfach geschachtelte Konstrukte werden durch Benutzung strukturierter Elemente vernünftig lesbar, GOTOs, Breaks u.ä. sind dagegen mehr oder weniger strikt verboten, da sie NICHT-strukturiert sind. In der Programm- Dokumentation gibt es für die Strukturen "Nassi-Shneiderman- Diagramme". Was ein Compiler macht, ist unerheblich, denn für Entwicklung und Wartung von Algorithmen ist die Struktur wichtig!. Googelt mal unter den obigen Stichworten, dann stoßt Ihr allenhalben auf Informatik-Links, die diese Sachverhalte behandeln. Fußnote: Es war schon zu Zeiten des Commodore C64 mit seinem unsäglichen (weil unstrukturiertem) BASIC möglich und dringend empfohlen, einen Algorithmus strukturiert zu entwerfen und beim Kodieren diese Elemente ersatzweise mit IF und GOTO- Konstruktionen zu realisieren. Der Vorteil liegt darin, dass bei einem Wechsel der Programmiersprache der Algorithmus praktisch keine Veränderungen erforderte, nur die Übersetzung in die Sprachelemente der neuen Sprache war notwendig! Ein vernünftig entwickelter Algorithmus ist und bleibt verstehbar und überdauert einige "Sprachmoden" ... MfG
> Mehrfach geschachtelte Konstrukte werden durch Benutzung strukturierter > Elemente vernünftig lesbar, GOTOs, Breaks u.ä. sind dagegen mehr oder > weniger strikt verboten, da sie NICHT-strukturiert sind. http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf
man kann breaks durch returns ersetzen, wenn man die Abbruchbedingung bzw. die Schleife in ein Unterprogramm packt. Wenn man es geschickt macht, bleibt der Code dadurch auch gut lesbar. und bei verschachtelten schleifen dient goto und co sogar der sauberen programmierung, da ansonsten der code durch Merker und deren Abfragen aufgebläht wird und so unübersichtlich wird. dass man nicht wild im code hin- und herspringt sollte klar sein. aber daraus abzuleiten, sprünge generell zu verbieten, ist lachhaft...
Jup, die Merker Setzerei find ich auch sehr sehr schwierig zum Nachvollziehen!!! Und stimme dir voll zu, dass gegen einen sinnvollen Einsatz von Sprüngen nichts spricht...
Netbird wrote: > ... GOTOs, Breaks u.ä. sind dagegen mehr oder > weniger strikt verboten, da sie NICHT-strukturiert sind. Diese Aussage geht meines Wissens nach auf einen sehr alten Artikel der Probleme mit Pascal behandelt zurück und hat dem armen unschuldigen GOTO einen echten Imageschaden zugefügt. Ich schliesse mich nico26plus1 und Miu an. Man sollte alle Möglichkeiten die einem eine Programmiersprache gibt auch nutzen, sicher sollte man mit einigen Dingen aufpassen und ja mit GOTO kann man grosse Verheerungen anrichten, aber mit Verstand eingestzt ist das alles was Gutes. -wiebel
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.