Warum goto vermeiden

BloedeFrage schrieb:
> Hallo, warum soll ich goto nicht nutzen?

Ich würde sagen, zu diesem Thema findest du bereits jedem Menge
Informationen und Diskussionen im Netz. Hast du schon alle gelesen? Wo
sind noch offene Detailfragen?

BloedeFrage schrieb:
> Hallo, warum soll ich goto nicht nutzen?

Weil die Erfahrung lehrt, dass so etwas bei jemandem der es nicht kann, 
ganz schnell zu unwartbarem Spaghetticode führt.

Es gibt Einsatzfälle für goto. Aber das sind ganz spezielle Fälle. 
Einfach mit goto wie wild drauf los programmieren, führt fast immer ins 
Chaos. Speziell bei Anfängern. Ein Profi hingegen braucht so etwas nicht 
zu fragen. Der weiß, wann ein goto tatsächlich die einfachste und beste 
Lösung ist und wann nicht.

BloedeFrage schrieb:
> GENAU aus dem Grund habe ich die Frage gestellt. Und habe jetzt,
> zumindest ein paar, brauchbare Einschätzungen erhalten. Es geht also vor
> allem um die Lesbarkeit, welche durch (schwer nachzuvollziehende)
> Sprünge leidet. Richtig?

Mal eine kleine Beispielfunktion (Arduino), die 2 zurückliefert, wenn 
man 1 als Parameter übergibt und die 1 zurückliefert, wenn man 2 als 
Parameter übergibt und ansonsten eine Fehlermeldung auf Serial ausgibt.

1

int tausche_1_2(int i)

2

// liefert 2 bei Eingabe 1

3

// liefert 1 bei Eingabe 2

4

// liefert sonst i und eine Serial-Fehlermeldung bei allen anderen i

5

{

6

  if (i == 1) goto skip_1; 

7

  if (i == 2) goto skip_2;

8

  goto error;

9

  skip_1:

10

  i = 2; 

11

  goto done;

12

  skip_2: 

13

  i = 1; 

14

  goto done;

15

  error:

16

  Serial.print("Falscher Eingabewert: ");

17

  Serial.println(i);  

18

  done: ;

19

  return(i);

20

}

Schöner geht es doch nun wirklich nicht, oder?
;-)

Bei den uralten BASIC Dialekten ist das mit dem GOTO übrigens dadurch 
gekommen, dass pro Programmzeile (das waren Interpretersprachen mit 
numerierten Zeilen) nach einer if-Abfrage nur ein einzelner Befehl 
ausgeführt werden konnte. Für if-Zweige gab es keine Codeblöcke. Daher 
war es dann eben oft so, dass als einziger erlaubter Befehl nach einer 
positiven if-Bedingung ein GOTO-Sprung gemacht wurde.

Seit alle Programmiersprachen Codeblöcke nach einer if-Bedingung 
erlauben (selbst BASIC kann das seit Jahrzehnten) ist GOTO relativ 
überflüssig.

Nützlich ist "goto" ist heute noch ggf. beim Herausspringen aus mehrfach 
verschachtelten for-Schleifen, wenn man aus einer der inneren 
for-Schleifen direkt herausspringen möchte.

Jürgen schrub:
>Nützlich ist "goto" ist heute noch ggf. beim Herausspringen aus mehrfach
>verschachtelten for-Schleifen, wenn man aus einer der inneren
>for-Schleifen direkt herausspringen möchte.


Das ist aber keine gute Idee, da mit GOTO herauszuspringen, weil das
jede Menge "Trümmer" hinterläßt.

Bei Bascom gibt es für solche Aktionen diese Befehle:
EXIT FOR

EXIT DO

EXIT WHILE

EXIT SUB

EXIT FUNCTION
*******************************************************************
Exit Paul

Paul Baumann schrieb:
> Das ist aber keine gute Idee, da mit GOTO herauszuspringen, weil das
> jede Menge "Trümmer" hinterläßt.
>
> Bei Bascom gibt es für solche Aktionen diese Befehle:
> EXIT FOR

Und aus einer dreifach geschachtelten for-Schleife nach diesem Muster 
springst Du mit Deinem Bascon dann wie heraus?

1

void nestedFor()

2

{

3

  for (int i=0;i<255;i++)

4

  {

5

    for (int j=0;j<255;j++)

6

    {

7

      for (int k=0;k<255;k++)

8

      {

9

        if (i==100 && j==20 && k==2) goto ende;

10

      }

11

    } 

12

  }

13

ende:  ;

14

}

Hast Du das "verschachtelt" in meinem Beitrag überlesen oder kannst Du 
bei Deinem BASCOM aus einer Dreifachverschachtelung vielleicht 
rausspringen indem Du schreibst
EXIT FOR FOR FOR
???

Natürlich gibt es auch unter C-Möglichkeiten, eine dreifach 
verschachtelte for-Schleife vorzeitig abzubrechen, ohne goto zu 
verwenden. Aber diese mehrfach verschachtelte for-Schleife wäre einer 
der wenigen Fälle, wo es mit goto eleganter als ohne goto möglich ist.

132 schrieb:
> NoGoTo schrieb:
>> 3. weils mit schlechter geht
>
> Ich kenne das auch so. Jeder erzählt es. Mich würde mal eine wirkliche
> Abhandlung darüber interessieren wieso es damit schlechter sein soll.

Der von Jürgen weiter oben gepostete Spaghetti Code reicht dir noch 
nicht?

Was ist leichter zu verstehen? Der Code da oben, oder

1

int tausche_1_2(int i)

2

{

3

  if (i == 1)

4

    return 2;

5

  if (i == 2)

6

    return 1;

7

8

  Serial.print("Falscher Eingabewert: ");

9

  Serial.println(i);  

10

  return i;

11

}

oder für die, die sich am Mehrfach-Return stören

1

int tausche_1_2(int i)

2

{

3

  int Result;

4

5

  if (i == 1)

6

    Result = 2;

7

8

  else if (i == 2)

9

    Result = 1;

10

11

  else {

12

    Result = i;

13

    Serial.print("Falscher Eingabewert: ");

14

    Serial.println(i);

15

  } 

16

17

  return Result;

18

}

Leider ist Jürgens Code von weiter oben (der zur Abschreckung gedacht 
war) so ziemlich genau das, was bei einem durchschnittlichen Anfänger 
rauskommt, wenn er hemmungslos goto verwendet. Er will bestehenden Code 
nicht verändern, muss ihn aber erweitern, also springt er mit einem goto 
quer durch die Gegend.

Diese ganzen Konstrukte wie 'if', 'for', 'while', 'else' laufen letzten 
Endes immer intern auf einen goto hinaus. Nur verpacken sie das ganze 
so, dass dieser implizite goto in einer strukturierten Form vorkommt und 
in geordneten Bahnen verläuft. Quasi eine freiwillige 
Selbstbeschränkung. Gerade Schleifenkonstrukte sind dafür ja ein 
Paradebeispiel: Im Grunde alles durch andere Konstrukte und einem goto 
ersetzbar.

BloedeFrage schrieb:
> Hallo, warum soll ich goto nicht nutzen?

Weil es viel bessere Lösungen gibt.

http://en.wikipedia.org/wiki/COMEFROM

;-)

Jürgen frug:
>Und aus einer dreifach geschachtelten for-Schleife nach diesem Muster
>springst Du mit Deinem Bascon dann wie heraus?

Bascom -mit "M" wie Matratze

Pass gut auf: Das ist nicht mein Bascom, es ist keine spezielle 
Version
für mich erstellt worden.

Solche Konstrukte wie Deines verwende ich nicht. Insofern ist mir das
vollkommen Titte!

Es ging darum, auf geordnete Weise aus einer Schleife 
herauszuspringen.

Paul

Es ist weitgehend egal. In PIC assembler muss man es andauernd 
verwenden.

Wichtig ist dass der Quelltext gut lesbar ist, wie dies erreicht wird 
ist egal.

Rolf Magnus schrieb:
> Gozo schrieb:
>>>In der Tat gibt es wenige gute Anwendungsszenarien für goto, aber es
>>>gibt sie!
>> Was wäre denn ein gutes Beispiel? Das Abbrechen einer verschachtelten
>> Schleife oder Fehlerbehandlung?
>
> Genau das sind die beiden sinnvollen Anwendungsfälle, die ich kenne.

In Java sind diese beiden Probleme durch labeled Statments gelöst. Damit
kann man mit break <label> beliebig verschachtelte Schleifen oder Blöcke
verlassen. Das break <label> stellt – wie auch alle anderen
Kontrollkonstrukte auch – ein verstecktes, aber eingeschränktes (und
damit weniger böses) goto dar und macht das goto fast völlig
überflüssig, weswegen es aus Java längst hinausgeschmissen wurde.

Auch andere etwas neuere Programmiersprachen bieten ähnliche Konstrukte
zum Verlassen verschachtelter Schleifen und zur übersichtlicheren
Fehlerbehandlung.

Es gibt aber noch ein paar weitere Anwendungen für Gotos. Zwei
Beispiele, die mir gerade einfallen:

- State-Machines: Hier werden mitunter Gotos für schnelle
  Zustandswechsel ohne eine explizite Zustandsvariable verwendet.

- Source-to-Source-Compiler: Die Generierung von goto-durchsetztem
  Spaghetti-Code ist oft einfacher als die Strukturierung des Codes in
  while…endwhile, for…endfor, if…else…endif usw. Da der generierte Code
  ohnehin nicht dazu gedacht ist, von Menschen gelesen zu werden, stellt
  das keinen großen Nachteil dar.

Yalu X. schrieb:
> In Java sind diese beiden Probleme durch labeled Statments gelöst. Damit
> kann man mit break <label> beliebig verschachtelte Schleifen oder Blöcke
> verlassen. Das break <label> stellt – wie auch alle anderen
> Kontrollkonstrukte auch – ein verstecktes, aber eingeschränktes (und
> damit weniger böses) goto dar und macht das goto fast völlig
> überflüssig, weswegen es aus Java längst hinausgeschmissen wurde.

.. in Java sollte man break labels auch vermeiden wenn moeglich, weil es 
eben so nah am goto ist ;)

Braucht man alles auch nicht wenn der Code sauber strukturiert ist, d.h. 
keine geschachtelten Schleifen bzw. keine anderen Kontrollstrukturen die 
direkt geschachtelt sind.
Jede Schleife in eine eigene Methode, dann reicht in 99% der Faelle ein 
return.

Peter II schrieb:
> wenn man z.b Bilddaten mit X und Y bearbeitet. Dann sind geschachtelten
> Schleifen sehr wohl sinnvoll. Dafür extra eine Funktion aufrufen ist
> wohl nicht immer die Lösung.

KOmmt auf den Kontext an.
Bei C etc. pp. mag das stimmen.
Bei Java gibt es absooluit keinen Grtund ekine eigenen Methode dafuer zu 
nehmen, siehe auch "Clean Code" von Bob Martin dazu..

Peter II schrieb:
> für mich die die goto lösung die übersichtlichste und vermutlich auch
> die schnellste.
> Die Version mit der Extra Funktion ist die langsamste.

In C vielleicht.. in Java sieht das anders aus, da kommt der JIT/Hotspot 
besser mit kleinen Methoden zurecht.
Ist aber voreilige Optimierung, in Java sollte definitiv der Quellcode 
im vordergrund stehen, nicht Pseudo Optimierungen.

Peter II schrieb:
> Warum sollte man auf ein Sprachfeature verzichten, wenn man damit kurzen
> und schnellen code schreiben kann?

Weil der Code schlecht zu lesen und warten ist.

Peter II schrieb:
> klar wenn du nie goto verwendest, kannst du den code auch nicht warten.
> Bei anderen gehört es einfach zur Sprache dazu und ist genauso normal
> wie der "?" Operator, und diese Leute haben kein Problem mit der
> Wartung.

Ich hatte noch nie das Beduerfnis goto zu verwenden, wozu auch?
Sehe keinen einzigen nutzen darin, ausser dass es den Code schlechter 
macht.

"Andere Leute" finden zB. auch PHP und Perl super, ich nicht.

Peter II schrieb:
> Wenn du aber jeden code mit goto als grundsätzlich schlecht Betrachtest
> macht eine weiter Diskussion keine sinn.

Wie gesagt, im Kontext Java ist das immer (fast) immer schlecht, wobei 
es ja in Java nur die break Labels gibt und ich diese dann verteufele ;)
goto ist in Java zwar reserviert, aber nciht belegt.

Dein Link zeigt C, da ist das eben ein anderer Kontext.

Wobei man jetzt auch argumentieren kann, dass das Auslagern von 
verschachtelten Schleifen in eigene Funktionen den ansonsten knackigen 
Algorithmus zerfleddert und er dadurch wiederum schlecht zu lesen und zu 
warten ist. Kommt wohl auf den Einzelfall an ...

Mladen G. schrieb:
> .. in Java sollte man break labels auch vermeiden wenn moeglich, weil es
> eben so nah am goto ist ;)
> ...
> Jede Schleife in eine eigene Methode, dann reicht in 99% der Faelle ein
> return.

Für mein Empfinden ist ein Return aus einer (evtl. verschachtelten)
Schleife schlechterer Stil als ein entsprechender Break, da letzterer
zwar eine oder mehrere Blockgrenzen, der Return aber zusätzlich noch
eine Methodengrenze überspringt.

Dass des von vielen Java-Programmieren anders gesehen wird, liegt
vielleicht auch daran, dass die break-<label>-Anweisungen und die Labels
selbst syntaktisch stark den Gotos bzw. den Labels in C ähneln.
Semantisch gesehen sind aber wesentlich restriktiver.

PHP verwendet beim break statt der Labels eine Zahl, die angibt, um
wieviele Ebenen beim Verlassen von verschachtelten Schleifen nach oben
gesprungen wird. Das gefällt mir syntaktisch besser, hat aber den
Nachteil, dass man bei langen Schleifenrümpfen nicht sofort sieht,
welche der Schleifen denn nun tatsächlich beendet werden und welche noch
weiterlaufen.

Yalu X. schrieb:
> Für mein Empfinden ist ein Return aus einer (evtl. verschachtelten)
> Schleife schlechterer Stil als ein entsprechender Break, da letzterer
> zwar eine oder mehrere Blockgrenzen, der Return aber zusätzlich noch
> eine Methodengrenze überspringt.

Wenn die Methode nur diese eine Schleife enthaelt, ist es "sauberer".

Die Clean Code Regeln aus Bob Martins Buch machen Sinn wenn man sie alle 
im Kontext sieht.
zB ist es gar kein Problem mehrere returns in einer einzigen Methode zu 
haben, denn Methoden haben auch sehr kurz zu sein, wieviele returns 
bekommt man in 3-5 Zeilen unter? ;)

Alexander B. schrieb:
> Wobei man jetzt auch argumentieren kann, dass das Auslagern von
> verschachtelten Schleifen in eigene Funktionen den ansonsten knackigen
> Algorithmus zerfleddert und er dadurch wiederum schlecht zu lesen und zu
> warten ist. Kommt wohl auf den Einzelfall an ...

Mag sein dass es im Einzelfall anders ist, aber dier generelle Regel nur 
eine einzige "Einrueckung" pro Methode zu haben funzt, Ausnahmen fuer 
spezielle Algorythmen (die man in Java mit der Lupe suchen muss) kann 
man ja machen.

In der Batch-Programmierung ist das gang und gäbe, weil man dort ohne 
GOTO nicht weiterkommt:
http://www.robvanderwoude.com/goto.php

Spaghetti mit Tomatensoße

Mladen G. schrieb:
> zB ist es gar kein Problem mehrere returns in einer einzigen Methode zu
> haben, denn Methoden haben auch sehr kurz zu sein, wieviele returns
> bekommt man in 3-5 Zeilen unter? ;)

Einverstanden.

Wenn die Methoden aber so kurz sind, muss man verschachtelte Schleifen
auf mehrere Methoden verteilen (das hast du weiter oben wahrscheinlich
auch so gemeint).

Wie kannst du dann aber von der innersten Schleife (die sich in einer
Methode befindet) aus die äußerste (in einer anderen Methode) verlassen?
Das geht doch nur dadurch, dass jede Methode ein entsprechendes Flag
zurückgibt, das in der Schleife der aufrufenden Methode abgefragt und
ggf. weitergereicht wird, und das über mehrere Ebenen.

Das wird doch beliebig kompliziert und trägt sicher nicht zur besseren
Lesbarkeit des Programms bei. Oder wie würdest du bspw. folgende Methode
in drei Methoden mit jeweils einer Schleife aufdröseln?

1

  int loop() {

2

    int x=0, y=0, z=0;

3

4

    loopz:

5

    for(z=0; z<10; z++) {

6

      for(y=0; y<10; y++) {

7

        for(x=0; x<10; x++) {

8

          if(condition(x, y, z))

9

            break loopz;

10

        }

11

      }

12

    }

13

    return x + y + z;

14

  }

Georg schrieb:
> Rolf Magnus schrieb:
>> Was für Trümmer soll das denn hinterlassen?
>
> Das kommt auch wesentlich auf den Compiler an. Soweit ich weiss gibt es
> welche, die einem Goto automatisch (magisch) Aufräumcode voranstellen,
> es gibt aber auch welche, die einen aus einer Prozedur herausspringen
> lassen ohne den Stack zu bereinigen.
>
> Nicht umsonst gibt es in manchen Firmen qualitätssichernde Vorschriften
> wie etwa die, dass eine Funktion immer nur einen Einsprungspunkt und
> einen Endpunkt haben darf.
>
> In Assembler darf man sowieso alles, aber das ist keine Entschuldigung
> für schlecht strukturierte Programme. Und wenn man tricksen muss, etwa
> aus einem Unterprogramm direkt in ein anders springen, sollte man das
> sorgfältig kommentieren, aber noch besser es sein lassen.
>
> Georg

Zeig mir mal einen modernen Compiler der es erlaubt aus der Prozdur 
(Pascal?) herauszuspringen. Das geht in C schon mal gar nicht.

In Embedded C bekommst du sofort einen Absturz wenn der Stack nicht 
stimmt.

Ausserdem koennen C funktionen durchaus viele Endpunkte haben- je nach 
Bedingung wird einer zuerst aktiv. Dadurch wird der Quelltext kuerzer 
z.b.

1

if(wert==1)return(0);else return(0xff);

kannste in dem Fall auch

1

return(wert);

 verwenden, aber es ist nur ein Beispiel, vielleicht ist Wert obskur und 
soll bereits in der Funktion umgesetzt werden.

Denk mal darueber nach:

1

i=7;

2

reloop:;

3

*(ch++)=0;if((i--)>0)goto reloop;

bewirkt auch nichts anderes als eine for schleife.

Mit dem Unterschied dass bei for die Bedingung zuerst abgefragt wird, 
hier wird der code innerhalb zumindest einmal abgearbeitet.

ausserdem, wenn du es aus irgeneinem obskurem Grund willst, kannst du 
den Wiederholpunkt auch noch von woanders anspringen. Das kann schon 
Sinn machen wenn du es mit Bitmaps zu tun hast, die u.U. alignment 
erfordern, u.U. aber auch nicht. Mit FOR musst du dann den Code nochmal 
wiederholen.

Ja klar mit zu vielen GOTOs versaust du dein Programm (zumindest den 
Quelltext).

Yalu X. schrieb:
> Wenn die Methoden aber so kurz sind, muss man verschachtelte Schleifen
> auf mehrere Methoden verteilen (das hast du weiter oben wahrscheinlich
> auch so gemeint).
>
> Wie kannst du dann aber von der innersten Schleife (die sich in einer
> Methode befindet) aus die äußerste (in einer anderen Methode) verlassen?
> Das geht doch nur dadurch, dass jede Methode ein entsprechendes Flag
> zurückgibt, das in der Schleife der aufrufenden Methode abgefragt und
> ggf. weitergereicht wird, und das über mehrere Ebenen.
>
> Das wird doch beliebig kompliziert und trägt sicher nicht zur besseren
> Lesbarkeit des Programms bei. Oder wie würdest du bspw. folgende Methode
> in drei Methoden mit jeweils einer Schleife aufdröseln?
>
>

1

>   int loop() {

2

>     int x=0, y=0, z=0;

3

> 

4

>     loopz:

5

>     for(z=0; z<10; z++) {

6

>       for(y=0; y<10; y++) {

7

>         for(x=0; x<10; x++) {

8

>           if(condition(x, y, z))

9

>             break loopz;

10

>         }

11

>       }

12

>     }

13

>     return x + y + z;

14

>   }

15

>

Das ist ein Beispiel, bei dem es wohl besser waere es nicht in einzelne 
Methoden aufzuteilen.

Muss aber ehrlich dazu sagen, dass ich dieses Konstrukt in 14 Jahren als 
Hauptberuflicher Java Entwickler noch nie brauchte.

Mit ist schon klar dass es wohl immer Ausnahmen geben wird, deswegen 
sehe ich auhc kein Problem mit einer Regel die sagt: "break labels 
sollten vermieden werden", weil es eben in den meisten Faellen wahr ist.

Ein aus meiner Sicht wichtiger Aspekt ist (neben der in einigen oben 
beschriebenen Fällen der besseren Lesbarkeit und klareren Struktur) goto 
erlaubt, kritischen Code sehr kompakt und sehr effizient zu schreiben 
bzw. zu kompilieren. Dabei geht es z.B. darum, dass der resultierende 
Code möglichst kurz ist (Cache footprint) und der wahrscheinlichste 
Codepfad sehr geradlinig ohne Sprünge abläuft (Prefetch queue /  branch 
prediction). Ein beliebter Trick ist dabei eben, in eine geradlinige 
(Assebler-) Codesequenz an beliebiger Stelle mit Goto einspringen zu 
können.

Dafür ist goto ein gutes Hilfsmittel, aber dafür gibt es noch andere 
Tricks (likely/unlikely bedingungen) und andere "angeblich" sehr böse 
sachen (switch/case fallthrough)

Peter II schrieb:
> bool doExit = false;
> for( x ... ) {
>    for( y ... ) {
>        if ( ... ) {
>           doExit = true;
>           break;
>    }
>    if ( doExit )
>       break;
> }

je nachdem wie die schleifen aufgebaut sind (z.b. eine matrix 
durchlaufen oder sowas in der richtung) könnte man das ganze auch 
dadurch abbrechen, dass man anstatt doExit = true die einzelnen 
abbruchbedingungen der schleifen quasi erzwingt.

sowas in der art

1

for(uint8_t x = 0; x < 128; x++) {

2

  for(uint8_t y = 0; y < 128; <++) {

3

    if(something) {

4

      x = UINT8_MAX;

5

      y = UINT8_MAX;

6

      break;

7

    }

8

  }

9

}

bitte nicht auf die konstanten festnageln - es geht ja nur ums 
prinzip...

Mladen G. schrieb:
> Das ist ein Beispiel, bei dem es wohl besser waere es nicht in einzelne
> Methoden aufzuteilen.
>
> Muss aber ehrlich dazu sagen, dass ich dieses Konstrukt in 14 Jahren als
> Hauptberuflicher Java Entwickler noch nie brauchte.

Ein ganz ähnliches Konstrukt ergibt sich, wenn man bspw. in einem
mehrdimensionalen Array ein Element mit einer bestimmten Eigenschaft
suchen möchte. So etwas läuft einem doch öfter über den Weg.

Manche Programmiersprachen bzw. Bibliotheken bieten aber auch die
Möglichkeit, verschachtelte Schleifen wie die obigen eben zu büglen, so
dass nur noch eine einzelne Schleife übrig bleibt, die mit einem
gewöhnlichen break verlassen werden kann. In python sähe das bspw. so
aus:

1

from itertools import product

2

3

def loop():

4

  for z, y, x in product(range(10), range(10), range(10)):

5

    if condition(x, y, z):

6

      break

7

  return x + y + z

Das Stichwort dazu lautet "Iteratoren", die es m.W. in ähnlicher Form
auch in der Java-Bibliothek gibt. Vielleicht kann man dort mit den
leidigen verschachtelten Schleifen ähnlich verfahren wie in Python.

Will man auch noch auf den break verzichten, der ja immer noch ein
Bisschen Goto-Charakter hat, kann man das Ganze in Python auch als
Generator-Comprehension schreiben:

1

def loop():

2

  return next((x+y+z) for z in range(10) for y in range(10) for x in range(10) if condition(x, y, z))

Diese Schreibweise hat Python übrigns von Haskell geerbt, wo das Genze
noch etwas kompakter geschrieben wird:

1

loop = head [x+y+z | z<-[0..9], y<-[0..9], x<-[0..9], condition x y z]

Da in Haskell die Liste ein Spezialfall einer Monade ist, kann man die
List-Comprehension (der Teil nach "head") auch im Monadenstil schreiben:

1

loop = head $ do

2

  z <- [0..9]

3

  y <- [0..9]

4

  x <- [0..9]

5

  guard (condition x y z)

6

  return (x + y + z)

Das sieht zwar nicht arg viel anders aus als das vorherige Beispiel,
aber die mit <-[0..9] endenen Zeilen sind jetzt getrennte Actions. Da
sie alle gleich aussehen, liegt es nahe, sie in eine Art Schleife zu
packen:

1

loop = head $ do

2

  [x, y, z] <- replicateM 3 [0..9]

3

  guard (condition x y z)

4

  return (x + y + z)

Die Zahl der verschachtelten Schleifen im ursprünglichen Java-Code
taucht hier in der zweiten Zeile als numerische Konstante (3) auf. Man
kann sie durch eine Variable n ersetzen, wenn man gleichzeitig dafür
sorgt, dass die Funktion condition und die Summe in der letzten Zeile
mit einer variablen Zahl von Operanden klar kommen. Das geschieht am
einfachsten dadurch, dass man die Variablen x, y und z zusammen durch
eine Liste (xs) mit n Elementen ersetzt. Das sieht dann so aus:

1

loop n = head $ do

2

  xs <- replicateM n [0..9]

3

  guard (condition xs)

4

  return (sum xs)

Dieser Code tut tatsächlich im Wesentlichen das Gleiche wie der
ursprüngliche Java-Code:

1

  int loop() {

2

    int x=0, y=0, z=0;

3

4

    loopz:

5

    for(z=0; z<10; z++) {

6

      for(y=0; y<10; y++) {

7

        for(x=0; x<10; x++) {

8

          if(condition(x, y, z))

9

            break loopz;

10

        }

11

      }

12

    }

13

    return x + y + z;

14

  }

Er ist aber kürzer und die Anzahl der verschachtelten impliziten
Schleifen ist variabel und kann über das Funktionsargument n gesteuert
werden. Der break im Java-Programm verbirgt sich implizit in der
head-Funktion, die das erste Element der durch den do-Block erzeugten
Liste zurückgibt. Da die restlichen Elemente nirgend benutzt werden,
werden sie auch nicht berechnet, was einem Abbruch der verschachtelten
Suchschleife gleichkommt.

Nicht nur der break, sondern auch die expliziten For-Schleifen sind
verschwunden. Sie sind irgendwo in die Tiefen der Laufzeitbibliothek
verlagert worden, ähnlich wie die impliziten Gotos der For-Schleifen in
Java in den Maschinencode der VM verlagert werden, wo sie niemanden
stören.

Diese Beispiel zeigt, dass man explizite Sprünge (Gotos) schrittweise
durch weniger explizite Sprünge ersetzen kann, bis am Schluss auf
Quellcodeebene nur noch linearer Code übrig bleibt. Linearer Code ist
das genaue Gegenteil vom Spaghetti-Code und deswegen nur minimal
fehleranfällig.

Bei der schrittweisen Umwandlung wurde sogar ohne großen Zusatzaufwand
noch Funktionalität hinzugewonnen (Iteration von n statt nur 3
Variablen), die sich mit den klassischen aus der strukturierten
Programmierung bekannten Konstrukten nur schwer realisieren lässt.

Trotzdem hat es sich ein Verückter nicht nehmen lassen, auch für Haskell
ein Goto nachzurüsten:

  http://hackage.haskell.org/package/GotoT-transformers-1.0/docs/Control-Monad-Trans-Goto.html

Ich vermute aber, dass es sich hier primär um einen Fall von "Und es
geht doch" ohne allzu viel praktischen Nutzen handelt. Auch für Python
hat jemand so ein Proof-of-Concept-Goto entwickelt. Es spricht immerhin
für die Mächtigkeit einer Programmiersprache, wenn so etwas mit
gewöhnlichen Sprachmitteln ohne Manipulation des Compilers und ohne die
Verwendung eines speziell dafür angefertigten Präprozessors möglich ist.

@Yalu
Ginge das auch mit einem range von 10000? Oder anders gefragt: Muss das 
product im Speicher Platz haben?

Ja klar nun starte ich Eclipse oder MPLABX auf meinem 1GB netbook, was 
sind schon 1GB, warte 3 Minuten, die Eingabe ist blockiert, irgenwann 
gehts dann sogar, umschalten, naja, warte 20 Sekunden.

desgleichen mit Skype und Web hotmail. Die brauchen FLASH und 
Silverlight um dir Werbung zu zeigen die du immer wieder aus versehen 
anclickst.

Ist dass nicht so eine Art GOTO gegen deinen Willen? Du clickst die 
Scroll Leiste, aber der Browser macht ein neues Fenster auf mit Skype 
Werbungsseiten die nutzlos sind und die du schon 20 mal gesehen hast.

Aber sei dir gewiss, der Source code enthaelt garantiert kein einziges 
GOTO.

Also ersteht es irgenwie wieder auf? Ach ja, liegt wohl daran das 1GB 
zuwenig Speicher ist.

Mit GOTO ist es halt so eine Sache, es ist ein linearer Ablauf, du 
befindest dich bei Punkt A, und gehst zu Punkt B aus irgeneinem Grund.

Im realen Leben kannst du das nicht vermeiden, oder wie ist da der 
objektorientierte Ansatz?

Naja wie schon oben beschrieben gibt es Anwendungen wo Goto sinnvoll 
ist.

Für so richtig eleganten Code braucht man aber natürlich das Comefrom, 
das in vielen Sprachen drin ist.

Konrad S. schrieb:
> @Yalu
> Ginge das auch mit einem range von 10000? Oder anders gefragt: Muss das
> product im Speicher Platz haben?

Karl hat schon fast alles dazu geschrieben. Um über alle Tripel in
product(range(10000), range(10000), range(10000)) zu iterieren, braucht
man also Speicherplatz für 3·10000=30000 Elemente.

Karl Käfer schrieb:
> Wenn man also anstelle von Yalus Codeproduct
>
>  (xrange(10), xrange(10), xrange(10))
>
> benutzt, dann wird bei jedem Aufruf von product() immer nur das
> aktuelle Ergebnis berechnet und im Speicher allokiert.

Das stimmt (leider) nicht ganz.

Zum einen ist in Python 3 range das, was in Python 2 xrange war. Es
liefert also keine Liste, sondern ein Objekt, aus dem sich ein Iterable
gewinnen lässt, das unabhängig vom Argument nur wenig Speicher belegt.
xrange ist deswegen in Python 3 obsolet. Wenn man die range-Funktion von
Python 2 benötigt, kann man diese mit list(range(n)) nachbilden.

Zum anderen (und jetzt kommt das "leider") erzeugt die product-Funktion
aus jedem der Argumente erst einmal eine Liste. Zumindest beim ersten
Argument ist das für mich nicht ganz nachvollziehbar, da dieses Iterable
nur ein einziges Mal durchlaufen wird und es deswegen keine Vorteile
bringt, die einzelnen Werte zu speichern.

Deswegen darf auch keines der Argumente unbegrenzt iterieren, obwohl das
beim ersten Argument (das der äußersten Schleife entspricht) schon
manchmal wünschenswert wäre und in anderen Sprachen, wie z.B. Haskell
auch tatsächlich möglich ist. Dort liefert

1

[[x,y] | x<-[0..], y<-[0..2]]

bzw.

1

sequence [[0..], [0..2]]

wie erwartet die endlose Liste

1

[[0,0],[0,1],[0,2],[1,0],[1,1],[1,2],[2,0],[2,1],[2,2],[3,0],...]

Eine Produktfunktion für Python, deren Speicherbedarf unabhängig von der
Größe der übergebenen Iterables ist und die damit auch mit endlosen
Iterables zurechtkommt, könnte in ihrer einfachsten Form so aussehen:

1

def product2(*iterables):

2

  if iterables:

3

    for x in iterables[0]:

4

      for t in product2(*iterables[1:]):

5

        yield (x,) + t 

6

  else:

7

    yield ()

Sie ist aber im Vergleich zum Original langsamer, da dieses nicht in
Python, sondern in C programmiert ist.

nicht"Gast" schrieb:
> if (status != 0)
>     {
>        I2C_reset(EEPROM_I2C_DEVICE);
>     }
>     return status;
> Wäre an der Stelle auch zu übersichtlich und lesbar (am Rande, status
> ist als Name schlecht gewählt :)

genau sowas (aber in einer etwas anderen Form) kann lästige auswirkungen 
haben.

nehmen wir folgende Code-sequenz, erstmal in der "optimalen" Variante 
ohne Fehlerbehandlung:

1

tu_was();

2

tu_nochwas();

3

du_nochwas_drittes();

4

aufraeumen();

schäön sequentiell, keine Sprünge die dir die Pipeline flushen, da kann 
er wie auf dem geraden Autobahnstück mit 300 Sachen drüberbrettern.

nun kommt die lästige Fehlerbehandlung:

1

tu_was();

2

if (!ok) {

3

   cleanup();

4

   return -E_BE_HAPPY;

5

}

6

tu_nochwas();

7

if (!ok) {

8

   cleanup();

9

   return -E_DONT_WORRY;

10

}

11

tu_nochwas_drittes();

12

if (!ok) {

13

   cleanup();

14

   return -E_DONT_KNOW;

15

}

16

cleanup();

17

return 0;

ist schon überhaupt nicht mehr geradlinig, dauernde Sprünge (die man 
aber mit likely() etwas entschärfen kann), aber, und das ist den 
wenigsten bewusst: cleanup() wird schlimmstenfalls vom compiler viermal 
inline eingesetzt, damit vervierfacht sich der ICache-Footprint! (ncoh 
schlimmer und unübersichtlicher wirds wenn ich nicht eine cleanup() 
habe, sondern drei oder mehr verschiedene die je nachdem wie weit er 
gekommen ist, aufgerufen werden müssen oder auch nicht)

natürlich kann man das auch anders schreiben:

1

tu_was();

2

if(ok) {

3

   tu_nochwas();

4

   if (ok) {

5

       tu_nochwas_drittes();

6

   }

7

}

8

cleanup();

Das inline-problem ist zwar weg, aber übersichtlicher ists auch nciht, 
speziell wenn ich nicht drei sondern mehr solcher if()s habe bin ich 
irgendwann am rechten Bildschirmrand... verschiedene Cleanups sind auch 
schwer unterzubringen, und sequentiell ists auch nicht gerade...

Was ist so schlimm daran, die ursprüngliche "Autobahn" zu verwenden, und 
dort wo notwendig ein "goto out" einzubauen?

nicht"Gast" schrieb:
> Goto wird leider überwiegend verwendet um schlechtes Design zu
> kaschieren.

Na na na na....

Yalu X. schrieb:
> Ein ganz ähnliches Konstrukt ergibt sich, wenn man bspw. in einem
> mehrdimensionalen Array ein Element mit einer bestimmten Eigenschaft
> suchen möchte. So etwas läuft einem doch öfter über den Weg.

Ich sag mal so: Ich weiss das andere das mal brauchten, selber ging mir 
das noch nie so.
Mehrdimensionale Arrays an sich sind etwas mit dem ich sehr selten 
direkt in Kontakt komme als Java Entwickler, zumnidest in meinem 
Bereich, das wird wohl auch der Gund sein warum ich ein break label noch 
nie brauchte.

nicht"Gast" schrieb:
> Schreib das doch mal mit gotos und zeig mir, dass das lesbarer ist.

fändest du weiter oben schon, aber bitte:

1

tu_was();

2

if (!ok) goto out;

3

tu_nochwas();

4

if (!ok) goto out;

5

du_nochwas_drittes();

6

out:

7

aufraeumen();

nicht"Gast" schrieb:
> if (    ! tuwas()
>      || ! tuwasanderes()
>      || ! tuwasdrittes())
>    ){
>    cleanup();

Einverstanden, geht aber nciht immer: tuwas() und co. sind in meinem 
Fall nicht als reine Funktionsaufrufe zu verstehen, sondern als 
(durchaus längere) Codesequenzen, die nicht so einfach einen Return-Wert 
haben

also eher so:

1

bereite_vor();

2

initialisiere();

3

berechne();

4

xxx();

5

hole_a()

6

if (!a) goto out;

7

tu_nochwas();

8

mach_was_mit_b();

9

x=a+b-27;

10

hallo=x(314)&0xl337;

11

if (hallo==0) goto out;

12

du_nochwas_drittes();

13

x();

14

y();

15

z();

16

out:

17

aufraeumen();

nebenbei:

nicht"Gast" schrieb:
> if (){
>    cleanup();
>    return ging_nicht;
> }
>
> cleanup();
> return ging;

2* Cleanup() ge-inlined :-(

nicht"Gast" schrieb:
> Leider ist das nicht wirklich ein
> Code aus dem wahren Leben, sondern zusammengestöpselter wirrer Kram.

Da hast du recht. ich hatte aber gehofft do könntest etwas besser 
abstrahieren...

nicht ganz so wirr, aber auch aus dem Zusammenhang gerissen:
[c]
        irqe.dest_id = entry->fields.dest_id;
        irqe.vector = entry->fields.vector;
        irqe.dest_mode = entry->fields.dest_mode;
        irqe.trig_mode = entry->fields.trig_mode;
        irqe.delivery_mode = entry->fields.delivery_mode << 8;
        irqe.level = 1;
        irqe.shorthand = 0;
        if (irqe.trig_mode != IOAPIC_EDGE_TRIG)
           goto out;

        spin_lock(&ioapic->lock);
        __kvm_ioapic_update_eoi(vcpu, ioapic, vector, trigger_mode);
        spin_unlock(&ioapic->lock);
        if (!vector)
           goto out;

        kvm->arch.vioapic = ioapic;
        kvm_ioapic_reset(ioapic);
        kvm_iodevice_init(&ioapic->dev, &ioapic_mmio_ops);
        ioapic->kvm = kvm;
        mutex_lock(&kvm->slots_lock);
        ret = kvm_io_bus_register_dev(kvm, KVM_MMIO_BUS, 
pic->base_address,
                                      IOAPIC_MEM_LENGTH, &ioapic->dev);
        mutex_unlock(&kvm->slots_lock);
        if (ret < 0)
           goto out;
[c]

Was ich sagen will: Du hast eine nicht ganz so kurze Sequenz fon 
Operationen (Zuweisungen, Funktionsaufrufe, berechnungen) die im 
normalfall einfach linear von vorne bis hinten durchlaufen werden. Die 
Blöcke kannst du auch nciht wie du oben vorgeschlagen hast, mit || 
zusammenhängen. An bestimmten stellen kann was schief gehen (ist aber 
die Ausnahme), und da bietet sich ein goto als "Ausstieg" an.

Für mich (und ich bin hier nicht alleine) viel besser lesbar als tiefe 
if() verschachtelungen.

nicht"Gast" schrieb:
> Du weist aber schon, dass deine Vorlage deutlich mehr Cleanups
> beinhaltet

Und wenn du mein kommentar dazu gelesen hättest, wüsstest du dass ich 
das absichtlich gemacht habe, um zu zeigen welche nachteile diese 
Konstellation hat :-(

Ich möchte hier noch eine andere Möglichkeit zur Diskussion stellen,
Initialisierungssequenzen mit Ausstiegspunkten ohne explizite Gotos und
verschachtelte Ifs in C zu realisieren. In folgendem Beispiel wird
angenommen, dass die drei Init-Funktionen im Fehlerfall einen von 0
verschiedenen Fehlercode liefern. Jeder Fail landet automatisch an der
dem BLOCK_END folgenden Anweisung.

1

#define BLOCK_BEGIN do {

2

#define BLOCK_END } while(0)

3

#define FAIL_IF(x) if(x) break

4

5

6

int main(void){

7

8

  BLOCK_BEGIN

9

10

    FAIL_IF( init1() );

11

12

    FAIL_IF( init2() );

13

14

    int n = some_computation();

15

16

    FAIL_IF( n < 0 || n > 9 );

17

18

    FAIL_IF( init3(n) );

19

20

    do_main_work();

21

22

  BLOCK_END;

23

24

  cleanup();

25

26

  return 0;

27

}

Mal an die Theoretiker und Praktiker hier:
Der diesjährige ICFPC startet in ein paar Minuten. Viel Spaß mit und 
ohne goto :)
http://icfpcontest.org/

emp schrieb:
>

1

> 

2

> void function()

3

> {

4

>     if(irengendwasKritisches() == false)

5

>         goto error:

6

>     if(irengendwasKritisches2() == false)

7

>         goto error:

8

>     if(irengendwasKritisches3() == false)

9

>         goto error:

10

> 

11

>     goto end;

12

> 

13

>     error:

14

> 

15

>     //Fehlerbehandlung, die immer gleich ist, sonst aber in jede 

16

> if-Anweisung rein müsste.

17

> 

18

> 

19

>     end:

20

> }

21

> 

22

>

>
> Schönes Wochenende

Die Variante mit den For-Schleifen finde ich toll, das hab ich so noch 
nie gesehen.

Was das letzte Beispiel angeht: Da kannst du auch gleich eine Funktion 
MyErrorHandler(ERR_TYPE) aufrufen und hast sogar eine Unterscheidung 
dabei. Mit nahezu gleichem Codeaufwand wie beim GOTO.

Daniel

Yalu X. schrieb:
> #define BLOCK_BEGIN do {
> #define BLOCK_END } while(0)
> #define FAIL_IF(x) if(x) break

Ich bin versucht zu sagen "real programmers don't use Pascal", aber ich 
verkneifs mir mal ;-)

Grundsätzlich natürlich eine Möglichkeit, nur: warum so viel Aufwand, 
nur um ein goto zu tarnen?

nicht"Gast" schrieb:

> Dein Code aus dem zweiten Post ist auch nicht der Renner.

ist nicht mein Code :-)

> Du scheinst zu viele Sachen in deine Funktion zu stecken. Ohne den Rest
> zu kennen: Teil das Ganze in kleinere Blöcke auf und du wirst sehen,
> dass das Ergebnis deutlich lesbarer als die Gotos sind.

nein, werde ich nicht. und das ist nicht mal unbedingt meine Meinung.

Der Code wurde recht wahllos aus den aktuellen Linux-Sourcen rauskopiert 
(irgendwas im KVM-Bereich)

Ohne jetzt einen Glaubenskrieg anzetteln zu wollen: Ich hab in meinem 
Leben sehr viel Code gelesen, viel guten Code, ein paar echte "perlen", 
und leider bei weitem zu viel schlechten Code. Für mich zählt der 
Linux-Kernel-Source auf jeden Fall zu den positiven Beispielen. Der Code 
ist gut, effizient, leistungsfähig, und durch viele Hände gegangen, und 
wurde von sehr vielen Augen gelesen. Goto ist dort alles andere als 
verboten, wird aber mit Bedacht eingesetzt.

Du kannst ja mal versuchen, dort zu predigen, wie du das alles viel 
besser machen würdest. Gib mir aber bitte vorher Bescheid, den Thread 
möchte ich nicht verpassen :-)

Ums nochmal auf den Punkt zu bringen: Goto hat absolut seine 
Berechtigung in gewissen Fällen: kritischer Code, kleiner 
(Cache-)Footprint, Rücksicht auf die Pipeline sind ein paar davon. Ein 
guter Programmierer kennt das, weiß das zu schätzen und kann einschätzen 
wann ein goto angebracht ist und wann nicht. Das reflexartige "goto ist 
böse" deutet nur auf eins hin: Die Aussage kommt nicht von einem 
guten, erfahrenen Programmierer.

Klaus Kaiser schrieb:
> 
http://programmers.stackexchange.com/questions/154974/is-this-a-decent-use-case-for-goto-in-c/154980#154980

Schön, danke! Trifft genau das was ich versuche zu vermitteln.

<duckundwegrenn>
nur müssten das die Mädels hier verstehen wollen...
</duckundwegrenn>

MCUA schrieb:
> oder anders gesagt, reine Geschacksache, was 'besser' lesbar ist.

W.S. schrieb:
> Man versuche das mal stringenter auszudrücken.

Jein

ich behaupte, goto macht den Code oft schlechter lesbar, (oft für 
"eingeweihte" durchaus auch besser)

Es geht aber nicht nur um die Lesbarkeit, sondern meist darum, dem 
Compiler zu erlauben, kompakten, effizienten und damit optimalen Code zu 
erzeugen.

In manchen Bereichen (OS Kernel, embedded mit "engen" bedingungen) ist 
das notwendig. ich weiss schon, "... the root of all evil", aber das 
obige Konstrukt von W.S. ist es wert, es sich anzugewöhnen. Es ist 
straight, sauber, optimal, schön.

(Leider wird man damit in der Ausbildung/Uni vermutlich Probleme 
bekommen. Liegt aber IMHO daran, dass Ausbildner selten viel 
Programmiererfahrung haben, eher Theoretiker sind. und in der Theorie 
gibts ja keinen Unterschied zwischen Theorie und Praxis, aber in der 
Praxis sehr wohl)

MCUA schrieb:
> Goto in ASM stiftet nur Verwirrung, weil es dort sinngemäss JMP heissen
> müsste
Wieso, es ist doch egal ob man zur Zieladresse hingeht oder springt...
Wenn sich der Hersteller für eines der beiden oder vllt. noch ein 
anderes  Mnemonic entschieden hat dann ist es ganz eindeutig was 
GOTO/JMP für diesen Prozessortyp bedeutet.

MCUA schrieb:
> Den Compiler hat das nicht zu jucken.

Leider sind wir noch nicht im Jahr 2525. Heute macht der Compiler noch 
was du tippst, und nicht was du willst.

nicht"Gast" schrieb:
> Trozdem bleibt das Stück Code scheiße.
Watch your language!

> Es
> fehlt einfach der Kontext um das beurteilen zu können. Wenn du die
> gesamte Funktion gepostet hättest, würde das sicher anders aussehen,
> aber so bleibt es unzusammenhängendes Geschwurbel.

www.kernel.org

Ich sprech dir jetzt einfach mal die Kompetenz ab, das zu beurteilen. 
Vermutlich ist es besser du schreibst weiter deine tic-tac-toe programme 
ohne goto's ...

<sorry>

MCUA schrieb:
> natürlich ist es wurscht, aber kein Mensch (ausser die von PIC)
> verwenden für JMP Goto in ASM. Warum der Quatsch? (doch nicht um mit
> 'goto' ein Hochsprachenkonstrukt im ASM zu assoziiren) (allerd. ist bei
> PIC (aus Urzeiten) syntakt. vieles anders).

Quatsch ist, sich darüber aufzuregen. Ich glaube nicht, dass alle 
Hersteller verpflichtet sind, die Nomenklatur von Intel zu übernehmen.