for-Schleife gegen über while-Schleife

[Luckie]

Delphi-Quellcode:

if not ende then 
  ende := not (i < length(SonnenStundenListe) - 1); 
while not ende do begin

Drei nots hintereinander. Schlimmer geht es glaube ich nicht mehr. Welhen Wert hat denn jetzt das ende in der whle-Schleife? Wenn es true ist, hast du eine Endlosschleife.

[jaenicke]

Zitat:

Zitat von oki

Bis jetzt wurde nur von gutem Stil und lesbarkeit gesprochen. Eine fachliche Begründung hab ich noch nicht gesehen (oder überlesen).

Es geht dabei auch nur um Stil und Lesbarkeit, nicht um Logik oder Performance des Programms. Die bessere Logik und Performance wird dabei absichtlich geopfert.

Rein vom erzeugten Assemblercode her wäre for + Break in vielen Situationen sauberer.

Ich persönlich setze daher die am besten passende, optimalste und performanteste Lösung ein, nicht eine realitätsfernere aus einem Lehrbuch.

[oki]

Zitat:

Zitat von jaenicke

Zitat:

Zitat von oki

Bis jetzt wurde nur von gutem Stil und lesbarkeit gesprochen. Eine fachliche Begründung hab ich noch nicht gesehen (oder überlesen).

Es geht dabei auch nur um Stil und Lesbarkeit, nicht um Logik oder Performance des Programms. Die bessere Logik und Performance wird dabei absichtlich geopfert.

Rein vom erzeugten Assemblercode her wäre for + Break in vielen Situationen sauberer.

Ich persönlich setze daher die am besten passende, optimalste und performanteste Lösung ein, nicht eine realitätsfernere aus einem Lehrbuch.

Da gehts mir jetzt aber wieder besser. Ich benutze Breaks eigentlich eher in recht kurzen Schleifen. Unübersichtlich sind die eigentlich eher nicht und verwirrt haben sie mich auch noch nie. Aber ich will hier nicht gegen den anerkannten Style reden.

Gruß oki

[omata]

Zitat:

Zitat von jaenicke

...nicht eine realitätsfernere aus einem Lehrbuch.

Blödsinn.

Schade, das es keinen Smily mit Kopfschütteln gibt.

[Hansa]

Zitat:

Welhen Wert hat denn jetzt das ende in der whle-Schleife? Wenn es true ist, hast du eine Endlosschleife.

Du mussst die ... beachten. 8) Gewöhne dir das Break/Exit nur an, aber mit dem Risiko, dass es eventuell (je nachdem wers sieht) als Design-Fehler gewertet wird. Im Gegensatz zu Delphi-Warnungen/Hinweisen kann das im Wiederholungsfall aber dann letztenendes als Error gewertet weden ! :mrgreen: C'est la vie. Hier gehts ja momentan nur um 10-Zeilen Schleifen, aber was wenn eine ein paar hundert Zeilen hätte ? Und mittendrin wird noch eine eigene Funktion aufgerufen, die Exit & Co. benutzt ? Selbst wenn man die im Verdacht hätte, dann genügt leider nicht mehr eine einzelne Stelle um Breakpoint, showmessage zu benutzen um unliebsame Effekte einzugrenzen, sondern man müsste die diversen Exits, Breaks... separat behandeln.

[omata]

Um es mal in einem Wort zu sagen: so etwas nennt man unstrukturierte Programmierung und exit, goto, break, ... sind nunmal unstrukturiert. Ich programmiere gern in einer höheren Programmiersprache und nutzte deshalb auch die Vorzüge strukturierter Programmierung. Genau aus dem Grund sind nunmal gewisse Befehle einfach nicht existent. Man braucht sie einfach nicht, sie sind einfach überflüssig.

[jaenicke]

Zitat:

Zitat von omata

Zitat:

Zitat von jaenicke

...nicht eine realitätsfernere aus einem Lehrbuch.

Blödsinn.

Das ist doch so. Was ich machen will ist, mir alle Einträge der Reihe nach nach einem bestimmten Kriterium anzuschauen. Und aufgrund eines bestimmten (unbestimmt eintretenden, ich weiß das ja vorher nicht, ob es eintritt) Ereignisses kann ich mir den Rest ersparen und daher schon vorher abbrechen. Das ist die Logik dahinter.

Das kann ich jetzt umbauen, indem ich von vorneherein davon ausgehe, dass dieses Ereignis (der Fund) eintritt und ich daher wahrscheinlich gar nicht alles durchsuchen muss.

Mir ist jedenfalls wichtiger, dass ein Programm schnell alles korrekt erledigt, als dass das Programm immer wieder kurz nachdenkt oder schon langsam startet, weil sich der Programmierer an irgendwelche starren Regeln gehalten hat.

Das erinnert mich irgendwie an das 18. Jahrhundert als z.B. die Kapitäne und Admirale der englischen Marine durch die Regeln der Seekriegsführung an bestimmte Vorgehensweisen gebunden waren, auch wenn diese die fast sichere Niederlage bedeuteten. :roll:

Und warum soll man extra umständlich mit while arbeiten, wenn Delphi die Optimierung eigentlich mit for selbst macht? for, eine Zeile:

Delphi-Quellcode:

for i := 0 to Length(SonnenStundenListe) - 1 do
  ...

while, äquivalenter Code:

Delphi-Quellcode:

MyArrayLength := Length(SonnenStundenListe);
i := 0;
while (i < MyArrayLength) do 
begin

  Inc(i);
end;

Dazu kommt dann in beiden Fällen noch die andere Bedingung. Wofür soll man den Delphiquelltext derart aufblähen. Das macht das ganze erst recht unübersichtlich.

Zitat:

Zitat von Hansa

Hier gehts ja momentan nur um 10-Zeilen Schleifen, aber was wenn eine ein paar hundert Zeilen hätte ?

Dann hat man im Regelfall einen Fehler gemacht. Normalerweise modularisiert man Code entsprechend.
Und dokumentiert natürlich auch so weit, dass der Code nachvollziehbar ist.

[Satty67]

Was steht in Clean Code zum Thema strukturierte Programmierung und Break?

Dort wird die bisherige Regel, niemals break und continue zu verwenden deutlich relativiert:

Zitat:

Zitat von Robert C. Martin 'Clean Code, aus Kapitel 3.11 dt. Ausgabe'

Wenn Sie Ihre Funktionen klein halten, dann richtet eine gelegentliche Anwendung von mehreren return-, break- oder continue-Anweisungen keinen Schaden an und kann den Code manchmal ausdrucksstärker machen, als die Ein-Eingang-Ein-Ausgangs-Regel.

[omata]

Für mich ist das nicht umständlich. Ich war noch nie Tippfaul und ob ich da nun eine Zeile spare ist nicht relevant für mich. Ich versuche strukturiert zu Programmieren. Deshalb sind die erwähnten Befehle nicht existent. Sie sind auch nicht nötig. Wenn man ohne sie nicht auskommt ist das ja ok, aber man programmiert dann eben nicht strukturiert, zumindest nicht an den Stellen, an denen man diese unstrukturierten Sprungbefehle benutzt.
Nach der Kompilierung wird ja sowieso alles zu Sprüngen und Vergleichen umgesetzt. Aber das ist ja gerade der entscheidene Vorteil einer Hochsprache, das man strukturell Programmieren kann. Will man das nicht, kann man genauso gut auch gleich in Assemblercode programmieren, den kann man dann auch hoch optimieren. Für mich geht es um das Lösen von komplexen Problemen und da interessiert mich nur die innere Schönheit und somit stabile Erweiterbarkeit von Systemen. Und diese Rubustheit erhält man nunmal eher, wenn man auf Strukturierte Programmierung setzt.
Wie gesagt, wer das nicht kann bzw. nicht will soll das so machen wie er will. Aber ich frage mich dann immer, warum soll ich mir so einen überflüssigen Blödsinn merken, wenn es auch ohne geht? Ich brauche nicht drüber nach zudenken, ob ich da jetzt ein exit setzt oder nicht. Da es für mich nicht existiert, stellt sich die Frage nicht.

Und dein tolles Kommentar, mit der vermeintlich Altertümlichen-Nicht-Dazu-Lernenden-Art ist quatsch, weil genau die Befehle, über die wird gerade diskutieren aus dieser Vergangenheit kommen. Also ein Starrsinn und Nicht-Dazu-Lernen ergibt sich hier nur, wenn man diese immer noch einsetzt.

@Satty67: ja ok, dabei liegt die Betonung aber auf gelegentlich. Also im Umkehrschluss nicht immer! Also nach dem Motto es gibt auch was anderes und es ist nicht notwendig und wie ich weiter oben ja schon geschrieben habe: Ausnahmen bestätigen die Regel. Ausnahmen!

[jaenicke]

Zitat:

Zitat von omata

Will man das nicht, kann man genauso gut auch gleich in Assemblercode programmieren, den kann man dann auch hoch optimieren. Für mich geht es um das Lösen von komplexen Problemen und da interessiert mich nur die innere Schönheit und somit stabile Erweiterbarkeit von Systemen.

Fragt sich dann nur was man mit einem schön geschriebenen aber langsamen und damit kaum benutzbaren Programm dann anfängt.

Der Internet Explorer 8 hat z.B. schöne Ideen und ich würde ihn sehr gerne einsetzen. Leider ist er aber so langsam, dass er für mich unbrauchbar ist. Ebenso der Firefox.

Die Verschwendung von Rechenzeit und Arbeitsspeicher ist heute nicht mehr so schlimm wie früher, aber absichtlich gar nicht zu optimieren finde ich trotzdem schlecht.

[Satty67]

Zitat:

Zitat von jaenicke

Die Verschwendung von Rechenzeit und Arbeitsspeicher ist heute nicht mehr so schlimm wie früher

Da fällt mir noch ein schönes Zitat ein:

"Die Hardware wird nicht so schnell schneller, wie Software langsamer wird."

[omata]

Vielen Dank, das du mir unterstellst, langsamen und ineffizienten Code zu schreiben. Meine Anwendung sind super schnell und doch hoch komplex, ich hatte bis jetzt keine Probleme. Aber, wenn du meinst.
IE, Chrome und Opera finde ich einfach schlecht und versuche da einen großen Bogen drum zu machen. Das einzig brachbare ist für mich in Sachen Browser der Firefox.
Also wir sind da komplett gegensätzlich, scheinen aber trotzdem beide keine Probleme zu haben. Das finde ich sehr interessant, es zeigt, das scheinbar alles egal ist.

[jaenicke]

Zitat:

Zitat von omata

Vielen Dank, das du mir unterstellst, langsamen und ineffizienten Code zu schreiben.

Welchen Code du sonst schreibst, weiß ich nicht. Ich rede nur von dem, um den es hier geht. :!:
Und hier ist while eben in der direkten Umsetzung ohne extra Variable usw. ineffizienter und langsamer.

Zitat:

Zitat von omata

Das einzig brachbare ist für mich in Sachen Browser der Firefox.

Wenn er schneller starten würde als er es tut, würde ich ihn auch gerne nutzen. So ist er für mich unbrauchbar.
Trotzdem wollte ich darüber gar nicht über Browser diskutieren, deshalb sage ich dazu nichts weiter, mir waren nur gerade IE und FF als erstes eingefallen als ich ein Beispiel für langsame Software schreiben wollte.

[omata]

Und ich schüttel weiter mit meinem Kopf wenn ich deine Zeilen lese. Einfach unfassbar... naja wie auch immer ich sage da jetzt auch nichts mehr zu.

[Hansa]

Warum fragst Du nach selber nicht überprüften Zitaten ?

Zitat:

Zitat von Satty67

Was steht in Clean Code zum Thema strukturierte Programmierung und Break?

Dort wird die bisherige Regel, niemals break und continue zu verwenden deutlich relativiert:

Zitat:

Zitat von Robert C. Martin 'Clean Code, aus Kapitel 3.11 dt. Ausgabe'

Wenn Sie Ihre Funktionen klein halten, dann richtet eine gelegentliche Anwendung von mehreren return-, break- oder continue-Anweisungen keinen Schaden an und kann den Code manchmal ausdrucksstärker machen, als die Ein-Eingang-Ein-Ausgangs-Regel.

Da steht im Kern : gelegentliche und manchmal Da sage ich nur : jo, indead, kann im Ausnahmefall vielleicht was bringen.

Zitat:

Zitat von Satty67

Da fällt mir noch ein schönes Zitat ein:

"Die Hardware wird nicht so schnell schneller, wie Software langsamer wird."

Bei dir vielleicht. Wie hat Bill Gates gesagt ? "640 kB reichen" :mrgreen:

[Luckie]

Zitat:

Zitat von Hansa

aber was wenn eine ein paar hundert Zeilen hätte ? Und mittendrin wird noch eine eigene Funktion aufgerufen, die Exit & Co. benutzt

Dann solltest du erstmal den Code aufräumen, denn dann hast du schon viel früher was falsch gemacht. Und eine aufgerufene Funktion, die Exit aufruft, stört meine Funktion nicht.

[Satty67]

Zitat:

Zitat von Hansa

Warum fragst Du nach selber nicht überprüften Zitaten ?

Verstehe nicht ganz, was ich vorher hätte prüfen sollen? Ich hab' das recht kleine Kapitel 3.11 nochmal komplett gelesen, bevor ich zitiert hab'. Was hätte ich sonst machen sollen. Es ging mir auch darum, das die Regeln für strukturiertes Programmieren in Lehrbüchern (also kein break in Schleifen) auch nicht von jedem Autor so streng ausgelegt wird, ganz im Gegenteil.

Zumindest ich hatte die ersten Aussagen so verstanden, das eine Variante Zeit spart und das kann gelegentlich bei großen Schleifen ein wichtiger Vorteil sein. Zu wissen, wie beide Varianten arbeiten, halte ich deshalb für sehr interessant. Es schreibt mir ja auch niemand hier vor, wie ich es machen soll, es bleibt ja mir überlassen. Bisher hab' ich hier im Forum Empfehlungen zum Code-Aufbau bekommen. Das war oft sehr logisch und nachvollziehbar, weshalb ich das auch dankbar übernommen hatte. Ich den meisten Fällen werde ich es aber so schreiben, wie ich es selbst am besten verstehe. Das mach für mich den meisten Sinn ;)

Ich denke die Diskussion hat unnötige Härte bekommen. Ich persönlich glaube einfach, das je nach Situation die eine oder andere Variante Vorteile hat und es manchmal einfach egal ist.

[alzaimar]

Lesbarer Code ist dann lesbar, wenn ihn jemand anderes mit halbwegs gleichem Kenntnisstand versteht.
So?

Delphi-Quellcode:

Function ExistsObjectIn3D (aKey : TSomeType) :  Boolean;
Var
  x,y,z : Integer;
Begin
  For x := 0 to MaxX do
    For y := 0 to MaxY do
      For z := 0 to MaxZ do
        If Space3D[x,y,z] = aKey Then Begin
           Result := True;
           Exit;
        End;
End;

Oder so?

Delphi-Quellcode:

Function ExistsObjectIn3D (aKey : TSomeType) :  Boolean;
Var
  x,y,z : Integer;
  
Begin
  Result := False;
  x := 0;
  While (x <= MaxX) and not Result do 
  Begin
    y := 0;
    While (y <= MaxY) and not Result do 
    Begin
      z := 0;
      While  (z <= MaxZ) and not Result do 
        If Space3D[x,y,z] = aKey Then 
          Result := True;
    End
  End
End;

Ich bevorzuge die erste Variante. Sie ist nahezu selbstdokumentierend.

Für 'Break' findet sich ein ähnliches Beispiel, wobei ich anstatt:

Delphi-Quellcode:

j := -1;
For i:=0 to Foobar Do
   If ValueExists(i) Then Begin
     j := i;
     break;
   End;

If j>=0 Then ...
...

Lieber eine lokale Funktion verwende:

Delphi-Quellcode:

...
  Function _IndexOfValue : Boolean;
  Begin
    For Result := 0 To Foobar Do
       If ValueExists (Result) Then Exit;
    Result := -1;
  End;

Begin
...
  If _IndexOfValue >= 0 Then
...
End;

Bei mir steht *immer* die Lesbarkeit (neben Wartbarkeit und Erweiterbarkeit) im Vordergrund. Das sind für mich die einzig geltenden Regeln. Wenn ein exit einen Code lesbarer macht, nur her damit. Selbst eingoto darf dann verwendet werden. Mir muss der Programmierer nur hinreichend erklären, wieso dieses Konstrukt hinsichtlich der geltenden Regeln (s.o.) die beste Wahl ist.

Und um den Bogen zur Ausgangsfrage zu spannen: Welches Schleifenkonstrukt nun verwendet wird, hängt wiederum von der Aussage ab, die getroffen werden soll. Denn Code hat eine Aussage: Er erklärt, wie ein Problem gelöst wird. Hier drei Lösungsansätze für das Problem: "Richtiges Verhalten zur Nahrungsaufnahme":
(1) While: "Solange Du Hunger hast, iss ein Brot"
(2) For / ForEach: "Für alle Brote: Iss sie auf"
(3) Repeat: "Iss ein Brot, bis du satt bist (keinen Hunger mehr has)"

(1) impliziert, das man keinen Hunger haben könnte,
(2) ignoriert ihn und
(3) verhindert eine Hungersnot.

Welches Konstrukt gewählt werden sollte, hängt also einzig und allein von der Aufgabenstellung ab (Gesunde Ernährung, Mästen, Abwenden von Hungersnöten).

PS: Um (2) zur gleichen Aussage wie (1) zu bewegen, benötigt man das "Break":
(2a) For / ForEach: "Für alle Brote: Iss sie auf, aber wenn Du währenddessen keinen Hunger mehr hast, hör auf".

[Luckie]

Komisch bei folgender Routine hat sich mir irgendwie eine while-Schlaife aufgedrängt. Ich weiß auch nicht warum:

Delphi-Quellcode:

function GetNextLowerPLZFromList(var PLZ: Integer; PLZSunHours: TPLZSunHours): Integer;
var
  i: Integer;
begin
  // Raises EPLZNotInList exception if no lower PLZ can be found
  i := High(PLZSunHours);

  while (PLZ < PLZSunHours[i, 0]) and (i > -1) do
  begin
    Dec(i);
  end;

  if i = -1 then
    Raise EPLZNotInList.Create(rsENotInList);

  PLZ := PLZSunHours[i, 0];
  Result := PLZSunHours[i, 0];
end;

[alzaimar]

:gruebel: Mir drängt sich dabei eher eine For-Schleife auf:

Delphi-Quellcode:

function GetNextLowerPLZFromList(var PLZ: Integer; PLZSunHours: TPLZSunHours): Integer;
var
  i: Integer;

begin
  For i:= High(PLZSunHours) downto 0 do
    If PLZ < PLZSunHours[i, 0] Then Begin
      PLZ := PLZSunHours[i, 0];
      Result := PLZ;
      Exit;
    End;

  Raise EPLZNotInList.Create(rsENotInList);
end;

Ich halte meine Version für verständlicher, da ich keinem erklären muss, wieso bei (i=-1) ein vorzeitiger Abruch der Routine erfolgt. Hier haben wir doch wieder ein Beispiel, das ein 'exit' den Code dezent kompakter und lesbarer macht.

Was habt ihr bloß gegen 'exit', 'break' und 'continue'? Wieso existieren diese Konstrukte auch in modernen Programmiersprachen? Ein Zugeständnis an Rookies? Wohl kaum, denn dann wäre 'goto' auch mit von der Partie.

Sind Exceptions nicht viel schlimmer, da sie ein globales goto repräsentieren, wobei noch nicht mal klar ist, wo das Sprungziel ist?

[Meflin]

Zitat:

Zitat von alzaimar

Was habt ihr bloß gegen 'exit', 'break' und 'continue'? Wieso existieren diese Konstrukte auch in modernen Programmiersprachen? Ein Zugeständnis an Rookies? Wohl kaum, denn dann wäre 'goto' auch mit von der Partie.

Versteh ich jetzt nicht. goto IST doch mit von der Partie :stupid: :gruebel:

[alzaimar]

Ich meinte C# und andere "hochmoderne" Sprachen (wenn man Delphi als archaisch bezeichnete). Außerdem wollte ich diese Religionsfrage nicht auch noch auf das Goto ausweiten.

[Chemiker]

Hallo,

Exit ist sogar noch in Delphi 2009 erweitert worden.

Bis bald Chemiker

[DasZiesel]

Zitat:

Zitat von Chemiker

Hallo,

Exit ist sogar noch in Delphi 2009 erweitert worden.

Bis bald Chemiker

Das wurde aber endlich einmal Zeit. :thumb: :bounce2:

[mkinzler]

Zitat:

Das wurde aber endlich einmal Zeit. Thumbs up! Bouncing 2

Warum?

[DasZiesel]

Zitat:

Zitat von mkinzler

Zitat:

Das wurde aber endlich einmal Zeit. Thumbs up! Bouncing 2

Warum?

Weil nun endlich möglich dies zu tun, was den Code übersichtlicher macht wie ich finde.

Delphi-Quellcode:

function Test(...): integer;
begin
 //... Code
 if not (..) then
 begin
   exit(-1);
 end;
end;

[Sven M.]

Kurze Zwischenfrage: Was gibt der Parameter an? Den Rückgabewert der Funktion?

[DasZiesel]

Ja. Das Result kannst du dir ab nun sparen.

[mkinzler]

Ist meiner Meinung ein hübsches Feature, für jemanden der oft Exit verwendet. Aber keine revolutionäre Neuerung

[DasZiesel]

Stimmt es ist nicht Revolutionär, aber für jemanden (wie ich) der viel mit Exit arbeitet z.B. in Funktionen/Prozeduren ein eher notwendiges Feature.

[mkinzler]

Man könnte auch versuchen, den Einsatz von Exit() zu begrenzen :zwinker:

[matashen]

Hab mir jetzt das alles durchgelesen und alles sehr interessant. Auch viele Gedanken dabei

Aber ich muss sagen, das ich bei vielen Fällen lieber eine repeat-schleife nehme, statt der while.

Die repeat schleife wurde hier fast gar nicht in betracht bezogen. (ausser bei der verteilung des Weltweiten Brotvorrats)

Die repeat liegt mir besser und ist in der deklaration meiner Meinung nach verständlicher. Das ist aber vermutlich geschmackssache.

Bei Delphi hab ich in seltenen Fällen exit und break gebraucht. Goto und labels nicht.

etwas OT:
Zur Zeit bin ich mehr im retrobereich unterwegs - natürlich nicht mit Delphi.
Da würden diese goto=nogo Grundsätze schon sehr schnell den Speicher fressen.
Da lernt man sehr effizienten Code zu schreiben, der auch auf kleinen Maschinen läuft und da gibts keinen weg vorbei an unstrukturierten Teile auch nicht um labels und goto.
Wenn also jemand dann in den Microcontrollerbereichwas machen will, sollte er diese Grundsätze nochmal überdenken und einen kleinen Reserveplatz für goto,break etc einräumen.
Schließlich will man ja vor dem Bedienterminal einer kleinen Anlage nicht 20 Sekunden nach einem Tastendruck warten bis man von der Struktur eine Rückmeldung bekommt.

noch mehr OT:
Hab gestern nen Programmeirerwitz gehört:
"Deine Mutter ist so fett das du nach dem instanzieren zwei Objekte bekommst". :mrgreen:

und es geht noch offtopicer:
könnte man die Weihnachtsmannsmilys nicht mal gegen Hasenohrensmilys tauschen.

Gruß Matthias

[mkinzler]

Zitat:

Die repeat schleife wurde hier fast gar nicht in betracht bezogen. (ausser bei der verteilung des Weltweiten Brotvorrats)

Und auf die Aufgabenstellung. Eine Repeat-Schleife ist nun mal nicht abweisend, d.h. wird auf jeden Fall einmal durchlaufen, eine While-Schleife nicht ( da abweisend)

[matashen]

Zitat:

Und auf die Aufgabenstellung. Eine Repeat-Schleife ist nun mal nicht abweisend, d.h. wird auf jeden Fall einmal durchlaufen, eine While-Schleife nicht ( da abweisend)

Die For-Schleife ist auch nicht abweisend.

[mkinzler]

Zitat:

Die For-Schleife ist auch nicht abweisend.

Kommt auf die Implementierung an. Ich dachte aber das es bei Delphi als While-Schleife implementiert ist. Da aber die Grenzen bei einer Zählschleife bekannt sind, sollte das egal sein

[Meflin]

Zitat:

Zitat von mkinzler

Ich dachte aber das es bei Delphi als While-Schleife implementiert ist.

JEDE Schleife ist im Endeffekt eine while-Schleife. Die ist ja sozusagen der Godfather der Schleifen :zwinker:

[matashen]

Zitat:

JEDE Schleife ist im Endeffekt eine while-Schleife. Die ist ja sozusagen der Godfather der Schleifen

Das ist nicht richtig so, der godfather von allen schleifen ist goto und label, auch wenns ejtzt manchen nicht gefällt, aber der Prozessor kennt keine schleifen, der macht alle schleifen in jumps

Gruß Matthias

[Meflin]

Zitat:

Zitat von matashen

Das ist nicht richtig so, der godfather von allen schleifen ist goto und label, auch wenns ejtzt manchen nicht gefällt, aber der Prozessor kennt keine schleifen, der macht alle schleifen in jumps

Ja, du hast Recht. Aber was ich eigentlich sagen wollte: repeat...until, for, for...in, for... downto, was auch immer sonst: alles das lässt sich allein durch while-Schleifen ausdrücken ;)

[matashen]

Da muss ich dir zustimmen,

bei einer Vereinfachung von Programmstrukturen ist while die letzte instanz vor unstrukturierten Befehlen.

ach so schön kann man sich einig sein.

was aber nicht bedeutet das eine while-Anweisung performanter ist als for mit break

Gruß Matthias

[mkinzler]

Aber (in den meisten Fällen) übersichtlicher und deshalb weniger fehleranfällig.