while(true)
   while(true)
      break 2; // springt aus beiden schleifen

Tja, das vermisse ich manchmal!

blöd, dass man mit break immer nur aus der innersten Schleife springen kann!
Bei einschlägigen Scriptsprache, wie PHP, ist es möglich, hinter break noch die "Tiefe" des Sprunges anzugeben.

while(true)
   while(true)
      break 2; // springt aus beiden schleifen

Tja, das vermisse ich manchmal!

Kennste goto ? Nimm goto

es gibt sehr sehr seltene anwendungsfälle bei gewisser if else logik wo ein goto die bessere lösung ist im vergleich zu einer unnötig komplizierten und unverständlichen ohne-goto variante

aber sowas gehört imo nicht zu den fällen wo goto angebracht ist denke ich

vielleicht solltest du deinen entwurf erstmal überdenken ob es so wirklich gut gelöst ist wenn du über eine größere tiefe als 1 breaken willst
ich vermute mal du musst nur 2 schleifen in die tiefe breaken, da würde eigentlich auch ein bool flag reichen und vermutlich auch die leserlichkeit und verständlichkeit fördern

aber wenn du meinst es geht wirklich nicht anders nimmt halt ein lokales goto welches innerhalb eines kleinen codestücks die sprungmarke hat so dass es überschaubar bleibt, allerdings musst du dir halt überlegen ob es das ist was du wirklich brauchst

while(true) 
   while(true) 
      break 2; // springt aus beiden schleifen

und

while(true)
   while(true)
      goto endOfLoops;
endOfLoops:

ist.
Ein Flag hingegen finde ich unlesbarer.
Imho ist goto gerade für das springen aus mehreren Schleifen geeignet.

Imho ist goto gerade für das springen aus mehreren Schleifen geeignet.

Da bist du nicht alleine da mit dieser Meinung.

while(true)

Weil irgendwann hat alles ein Ende.

2.Warum ist ein Flag schwerer zu lesen ? Das ist Aufgabe des Programmierers für vernünftige Dokumentation des Codes zu sorgen.

Der Nachteil von Spaghetticode, ist dass er schwer nachzuvollziehen ist und das ist in diesem Fall nicht gegeben.

In welchem Fall ? Bei den genannten Beispielen ?

Mir ist schon oft aufgefallen, dass die ganzen Diskussionen über Kontrolstrukturen nur von Leuten geführt werden, die riesige Funktionen schreiben. Wer ordentlich programmiert, braucht solche "Features" nicht.

Und irgendwas mit irgendwelchen Flags rumzuhantieren ist weniger gut nachzuvollziehen als ein brich die Schleife jetzt ab.

Dem stimme ich zu. Aber dann würde ich die Schleife mit einem return abbrechen. Ich sag jetzt schon nicht, dass jedes break böse ist, aber return ziehe ich klar vor. Auf jeden Fall behaupte ich, dass ein break 2 böse ist. Ich weiß, es gibt keine absolute Wahrheit bei sowas, aber man braucht sich das Leben schon nicht irre kompliziert machen, damit man ja nicht die eine Gelegenheit verpasst, wo ein break 2 die beste Lösung scheint. Da ist es leichter, break 2 und goto zu verteufeln, da verpasst man jetzt schon nichts.

btw. Eine Schleife hat ja normal irgendeinen bestimmten Zweck, diesen Zweck kann man benennen und schon hat man eine Funktion. Man kann auch aus einer geschachtelten Schleife returnen. Es ist viel leserlicher.

Fhul, du sagst man würde in einen komplett anderen Programmteil geworfen, aber das ist nicht wirklich so, man bricht lediglich die Schleife ab

Du springst an die Stelle, die du definierst. Ob das nun direkt nach den Schleifenrumpf ist kann sein, muss aber nicht.

Einfach den Code besser in Funktionen verteilen und schon ist das ganz hinfällig.

Benutzername: schrieb:

Der Nachteil von Spaghetticode, ist dass er schwer nachzuvollziehen ist und das ist in diesem Fall nicht gegeben.

Spätestens wenn etwas mehr Inhalt in der Scheife dazukommt ist es wieder gegeben. Und Programmierer sind (zumeist) faul [Nicht unbedingt weil sie es wirklich sind, sondern weil es etwas gibt das sich Zeitdruck nennt] und ändern dann nicht zwangsweise den Code wieder ab.

Es gibt immer bessere Alternativen als goto. Ich komme seit 19 Jahren ohne goto aus (um genau zu sein, seit ich programmiere; Mag vielleicht auch daran liegen das ich die Programmierung unter gewisser Aufsicht erlernt habe, mein Vater ist auch in der Programmierung und QS Tätig ;p), da solle es auch anderen möglich sein es zu umgehen.

cu André
P.S: Und davon abgesehen sind tiefe Schleifenverschachtelungen auch meist nur ein Zeichen unschönen Codes. Meist läuft das mit langen Funktionen einher, und die sollte man eh lieber in ihre Einzelteile untergliedern. Alleine schon der Lesbarkeit wegen.

http://stevemcconnell.com/ccgoto.htm

Wie wäre es mal mit einem anständigen Programmierstil? PHP ist eine Frickelsprache und kann als Vorbild nicht herhalten. Die ganze Diskussion break, break mit Zahl, goto usw. ist überflüssig, wenn man gescheite, vernünftige, kleine Funktionen schreibt.

Mir ist schon oft aufgefallen, dass die ganzen Diskussionen über Kontrolstrukturen nur von Leuten geführt werden, die riesige Funktionen schreiben. Wer ordentlich programmiert, braucht solche "Features" nicht.

Java hat weder break X noch goto. OMG wie kann man da nur Programme schreiben?

asc hat mich dadrauf aufmerksam gemacht das ich auch noch nie goto eingesetzt habe und ich programmiere jetzt seit 13 Jahren.

wer meint es gibt fett-gedruckt-immer bessere lösungen als gotos kann sich ja diesen artikel durchlesen
http://stevemcconnell.com/ccgoto.htm

und natürlich den klassiker: http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf

Ein goto erzeugt wie schon gesagt immer Spaghetticode.
Du springst aus deinem nachvollziehbaren Ablauf an eine andere komplett andere Stelle des Programms.
Und je umfangreicher und verschachteleter der Schleifenrumpf oder Rümpfe umso schlimmer wird das.
Ein goto ist nicht nur manchmal böse.

Manchmal ist ein goto auch Sinnvoll. Zumindest in C.

Sowas ist unschön:

int fehler = 0;
if (expr1) {
  ...
  if (expr 2) {
    ...
    if (expr3) {
      ...
      if (expr 4) {
         ...
      } else {
        fehler = 1;
      } 
    } else {
      fehler = 1
    }
  } else {
    fehler = 1;
  }
} else {
  fehler = 1;
}

if (fehler) {
  [ aufräumen ]
  return FEHLER;
} else {
  return ERFOLG;
}

schöner

if (!expr1) {
  [ aufräumen ]
  return FEHLER;
}

if (!expr 2) {
  [ aufräumen ]
  return FEHLER;
}

if (!expr3) {
  [ aufräumen ]
  return FEHLER;
}

if (!expr 4) {
  [ aufräumen ]
  return FEHLER;
}

// aufräumen

Weniger fehleranfällig und erheblich besser zu lesen:

if (!expr1) {
  goto ERROR_CLEANUP;
}

if (!expr 2) {
  goto ERROR_CLEANUP;
}

if (!expr3) {
  goto ERROR_CLEANUP;
}

if (!expr 4) {
  goto ERROR_CLEANUP;
}

return ERFOLG;
ERROR_CLEANUP:
  [ aufräumen ]
  return FEHLER;

In C++ braucht man sowas nicht mehr und es wäre auch nicht Exception-Sicher. Aber in C trägt sowas zu Lesbarkeit bei.