Diskussion zum Thema GOTO in der Shoutbox - Zusammenfassung

**Musashi**

Diskussion zum Thema GOTO in der Shoutbox - Zusammenfassung

Vorwort :

In der Shoutbox laufen häufiger Diskussionen, die interessante Einblicke in programmiertechnische Hintergründe und Standpunkte liefern. Leider verschwinden diese Beiträge recht schnell im Archiv, und geraten dann in Vergessenheit (finde ich persönlich sehr schade).

Zudem ist die Shoutbox nur registrierten Mitgliedern zugängig, da sie auch persönliche, spaßige oder völlig themenfremde Beiträge enthalten kann.

(Info für Gäste : Die Shoutbox ist eine Art forumsinterner Kurznachrichtendienst)

Ich hoffe, ich setze mich mit dieser Zusammenfassung nicht der allgemeinen Steinigung aus .

Ich habe sehr darauf geachtet, dass keine Formulierungen vorkommen, die ich nicht auch schon in 'normalen' Forenbeiträgen gelesen hätte .

Gruß Musashi

Beiträge vom 30.01.2018 bis zum 31.01.2018 (21:08)

- die Reihenfolge ist chronologisch, beginnend mit dem ältesten Beitrag

- gravierende Tippfehler habe ich weitgehend beseitigt

- etwaige Bezüge zu Firmen etc. wurden mit [xxx] unkenntlich gemacht

Ausgangspunkt war die Frage, warum 'script breaking changes' gemacht werden :

Verfasser : AspirinJunkie

In der Regel wenn eine Entwicklung über die Zeit in eine Sackgasse gerät und nur durch einen Cut wieder ins Lot gebracht werden kann. Alternativ um die Benutzer zu erziehen , z.B. der Wegfall von goto würde mir da einfallen (obwohl ich persönlich diesem selbst nicht sehr negativ gegenüber stehe).

Verfasser : Peter S. Taler

AspirinJunkie, das ist wohl das beste Beispiel für Bevormundung. GOTO gibt Spagehtti Code, GOTO ist uncool, GOTO geht gar nicht - stundenlang könnte ich so weitermachen. Was folgt, der User wird erzogen ! GOTO wird ausgemistet. Gut der User läßt sich nicht erziehen - nun springt er halt zu Funktionen. Was ist aus der Sicht der GOTO "Hasser" daran besser ? Nichts?

Im Zweifel springe ich auch mal zu einer Funktion - finde ich manchmal sinnvoller als IF THEN ELSE noch tiefer zu verschachteln.

Verfasser : alpines

Das Problem bei GOTO ist, dass Scopes inkonsistent werden. Handles können dabei vergessen werden zu schließen und das kann schnell in einer StackOverflow-Exception enden.

Verfasser : autoiter

Zitat von Peter S. Taler :

"GOTO wird ausgemistet. Gut der User läßt sich nicht erziehen - nun springt er halt zu Funktionen. Was ist aus der Sicht der GOTO "Hasser" daran besser ? Nichts ?"

GoTo und Aufruf von anderen Funktionen ist etwas völlig anderes.

PS: Ich fand die GoTo Funktion auch nicht so schlecht. Aber wer vermisst sie schon wirklich ?

Verfasser : chesstiger

goto ist wirklich praktisch. In C z.B. benutze ich es gern. Wenn man es verantwortungsvoll nutzt, kann man so gut leserlichen und effizienten Code schreiben. Schwierig wird es nur, wenn man versucht, zwischen verschiedenen Kontexten hin und her zu springen. Da muss man schon GENAU wissen, was man tut, sonst zerschießt man sich einfach den Stack.

Verfasser : Andy

Abschließend zum Thema GOTO: Jeder Compiler erzeugt Maschinencode (genau wie ein Assembler) und in eben diesem Maschinencode wimmelt es nur so von GOTO´s. Weil es außer CALL keine anderen Sprünge gibt.

Jetzt stellt sich die Frage an die "GOTO MUSS WEG"-Fraktion, wieso das GOTO durch irgendwelche anderen Konstrukte ersetzt werden MUSS, wenn der Prozessor letztendlich doch massenweise GOTO´s verarbeitet?! Seit 30 Jahren warte ich da auf eine Antwort, aber da kommt nix....wieso auch, man müsste ja zugeben, dass der Weg von (ach so unleserlichem) Binärcode über (oh weh was ein unleserlicher) Assemblercode zu den (NATÜRLICH) wesentlich besser lesbaren "Hochsprachen" (außer Basic, das nutzen nur Noobs, das hat nämlich ein GOTO), über dummschwätzende sog. "Programmierer" geht, die mit ihrem eigenen (Spaghetti-Hochsprachen-) Code nicht mehr klarkommen!

O-Ton einer gesamten [xxx]-Abteilung auf meine Nachfrage wieso hunderte Zeilen Quellcode neu geschrieben werden anstatt den bestehenden (C-)Code zu debuggen:

"Neu schreiben geht wesentlich schneller, wir blicken in dem ursprünglichen Code selbst nicht mehr durch !"

Das war Mitte der Achtziger, und heute ist das meist nicht viel besser.....ein HOCH auf die "Hochsprachen".

EDIT :

in der O-Ton-Zeile zu [xxx], das waren natürlich hunderttausende Zeilen Code...aber die Jungs damals haben auch noch Prämien für Kommentarzeilen im Code bekommen

Verfasser : AspirinJunkie

Ich bin zwar kein Gegner von Goto, aber der Zusammenhang mit dem Assembler-Kompilat hinkt ein wenig. Dass der Code intern wieder in Goto-Konstrukte übersetzt wird widerspricht den Argumenten gegen Goto nicht. Die Probleme von Goto treten im Kompilat nicht mehr auf, da die Konstrukte der Ausgangssprache, welche im Maschinencode per Goto übersetzt werden, gar nicht die problematischen Konstrukte erzeugen können wie sie stattdessen mit Goto möglich wären.

Mit einer While-Schleife z.B. kann man halt nicht einfach mal so in den fremden Scope einer Funktion springen wie es mit Goto machbar wäre. Dennoch wird diese Schleife im Kompilat per Goto umgesetzt.

In Assembler kann man auch mit Goto viel Mist anstellen. Der Verzicht auf Goto in Hochsprachen soll hingegen dazu führen, dass der daraus erzeugte Maschinencode von derart fragwürdigen Sprunganwendungen frei bleibt.

Es gibt auch einige Regeln die, wenn sie konsequent eingehalten werden, die Problematik von Goto deutlich minimieren. Z.B. nur Vorwärtssprünge, nur innerhalb des selben Scopes etc. Jetzt wäre es jedoch am User diese einzuhalten. Daher kann ich schon verstehen, dass bei Sprachen die sich an Einsteiger- und Gelegenheitsprogrammierer richten auf Goto (und damit auch dessen Vorteile) zu Gunsten der Vermeidung dieser Fälle verzichtet wird.

Also ich kann daher damit leben, dass die AutoIt-Entwickler Goto aus AutoIt entfernt haben.

Bei sowas wie C würde ich es nicht verstehen. Daher habe ich auch wenig Verständnis für das Fehlen von Goto in Java.

Verfasser : chesstiger

Das könnte man ja vorschreiben. Wenn man Goto implementiert, kann man ja Regeln festlegen.

**Oscar**

Wenn wir es mal auf AutoIt beschränken, dann ist GOTO überflüssig. In der ganzen Zeit, in der ich AutoIt bisher nutze (über 11 Jahre), habe ich das GOTO jedenfalls nie gebraucht.

In AutoIt haben wir drei Schleifen (For...Next, While....WEnd und Do...Until), wozu also ein Goto?

In Assembler ist das etwas anderes. Dort ist das JMP mitunter nicht verzichtbar. Das liegt aber auch daran, weil man es für Schleifen braucht.

Goto führt meistens, besonders bei Programmiereinsteigern, zu dem berühmt/berüchtigten Spaghetticode.

Natürlich kann man auch ohne Goto unleserlichen Code schreiben (das missbrauchen der Funktionen ist da sehr beliebt). Das weglassen von Goto macht einen nicht automatisch zum guten Programmierer.

Ich denke aber, dass man sich ohne Goto mehr Gedanken über den Programmablauf macht und vielleicht eher damit anfängt das Programm in kleine Teilprobleme aufzuteilen, die sich dann mit Funktionen abbilden lassen.

**Musashi**

Hallo Oscar !

Wie stehst Du grundsätzlich zu der Idee, interessante Shoutbox-Diskussionen in den allgemein zugänglichen Forumsbereich zu überführen (z.B. wie hier als Zusammenfassung) ?

Diese Frage geht im Prinzip an alle !

Ich finde es, wie gesagt, immer schade, wenn solche Informationen 'verschwinden' bzw. für Gäste unzugänglich sind. Natürlich müssen dabei persönliche Daten, flapsige Ausdrucksweisen etc. editiert/entfernt werden .

Ich kann mich z.B. an eine Diskussion in der SB erinnern, in der BugFix nach dem Sinn von Const ByRef in Funktionsdeklarationen gefragt hat, Zitat :

"Func _anyFunction(Const ByRef $hWnd, Const $sTxt). Hat jemand eine Erklärung, weshalb dort das (in meinen Augen sinnfreie) Keyword Const verwendet wird ?"

Der nachfolgende Austausch von Argumenten, u.A. von AspirinJunkie , war sehr informativ .

Gruß Musashi

**Oscar**

Zitat von Musashi

Wie stehst Du grundsätzlich zu der Idee, interessante Shoutbox-Diskussionen in den allgemein zugänglichen Forumsbereich zu überführen (z.B. wie hier als Zusammenfassung) ?

Wenn es sich um Themen handelt, die ausführlicher diskutiert werden können oder die insgesamt von Interesse sind oder sein können, warum nicht?

Da ist das Forum doch besser lesbar, als in der Shoutbox, wo die alten Beiträge dann oben verschwinden (nur noch im Archiv lesbar sind).

Peter S. Taler · *Ab 19-10-22 ergänzt um:*

Nette das aus der Shoutbox herauszuholen. Ich erwarte nach den folgenden Zeilen meine sofortige Steinigung!

1) Ich brauch auch kein goto aber....

auch wenn es (vielleicht) meinen Horizont überschreitet für mich ist kein so großer Unterschied zwischen GOTO und einem Funktionsaufruf.

Ich springe von einer Position zur anderen... Programmtechnich mag das "etwas anderes " sein. Fallweise kann Code lesbarer werden, durch die Springerei. Wwenn man wie wild umsich schlägt versinkt man natürlich im Chaos. Andererseits wird Code durch Springen zu (sprechenden) Funktionen auch nicht (unbedingt) lesbarer, als durch Springen mit GOTO sofern hinter dem GOTO eine anständige Beschreibung steht.

Scripttechhnisch ist es für mich kein Unterschied! (Bitte ein wenig leben lassen).

Klar ist auch, dass eine gewisse Disziplin zum schreiben von anständigen Code wohl unabenderlich ist.

Im übrigen war es für mich eigentlich nur ein flapsiges Beispiel wie manchmal Prinzipien geritten werden Denn manche semantische Umstellung in einer Programiersprache - ist für die Fische...

Gruß

Peter

**Oscar**

Zitat von Peter S. Taler

Andererseits wird Code durch Springen zu (sprechenden) Funktionen auch nicht (unbedingt) lesbarer

Wenn Du Funktionen dazu verwendest, um das fehlende Goto auszugleichen, dann hast Du den Sinn von Funktionen noch nicht verstanden.

Peter S. Taler · *Ab 19-10-22 ergänzt um:*

Oscar

tas tut nun doch weh - ich hatte doch gebeten - leben lassen!

Gruß

Peter

**Oscar**

Na gut, um Dir etwas mit auf den Weg zu geben:

Wenn Du "wild" von einer Funktion zur nächsten springst und von dort dann wieder zur nächsten und so weiter, dann wird Dir das Programm irgendwann abstürzen (Stichwort: begrenzte Rekursionstiefe).

Eine Funktion ist dazu da, aufgerufen zu werden, dann werden dort Berechnungen durchgeführt und sie muss mit Return (na gut, das ist in AutoIt optional) wieder verlassen werden. Jedenfalls muss die Funktion bis zum EndFunc kommen oder vorzeitig mit Return verlassen werden.

Anderenfalls erzeugst Du eine rekursive Funktion ohne Abbruchbedingung und die stürzt früher oder später ab (stack overflow).

Ein Beispiel dafür:

AutoIt

Test1()

Func Test1()
    Test2()
EndFunc

Func Test2()
    Test3()
EndFunc

Func Test3()
    Test1()
EndFunc

Alles anzeigen

Hier wird quasi nie das EndFunc "ausgeführt". Es wird vorher immer zur nächsten Funktion gesprungen.

In diesem Beispiel kann man das leicht überblicken, aber in richtigen Programmen sollte man einen Funktionsaufruf nicht als Goto-Ersatz missbrauchen, weil es genau zu obigen Verhalten führen kann.

Peter S. Taler · *Ab 19-10-22 ergänzt um:*

@ oscar danke für die Nachhilfe ... Du solltest den Vergleich zwischen GOTO und Funktionsaufrufen nicht gar so wörtlich nehmen. Im übrigen hat niemand davon gesprochen im Kreis rum zu springen - im Gegenteil - ich sprach von Disziplien.

Man muss nicht immer gleich vom schlimsten ausgehen :). Wer Code in der Art Deines Beispiels produziert - dessen Programm stürtzt schon aus anderen Gründen ab

Gruß

Peter

**Oscar**

Sicher, mein obiges Beispiel ist die Extremversion.

Aber was ist hiermit:

AutoIt

#include <AutoItConstants.au3>
#include <ButtonConstants.au3>
#include <GUIConstantsEx.au3>

$iRek = 0
Eingabe()

Func Eingabe()
    Local $hGui = GUICreate('Eingabe', 400, 90)
    Local $idInput = GUICtrlCreateInput('', 10, 10, 380, 20)
    Local $idNext = GUICtrlCreateButton('Nächste Eingabe', 130, 50, 120, 25, $BS_DEFPUSHBUTTON)
    Local $idCancel = GUICtrlCreateButton('Abbruch', 260, 50, 120, 25)
    GUISetState()
    While True
        Switch GUIGetMsg()
            Case $GUI_EVENT_CLOSE, $idCancel
                GUIDelete($hGui)
                ExitLoop
            Case $idNext
                GUIDelete($hGui)
                $iRek += 1
                ToolTip($iRek, Default, Default, 'Test', $TIP_WARNINGICON)
                Eingabe()
        EndSwitch
    WEnd
    Return
EndFunc

Alles anzeigen

Auf den ersten Blick völlig in Ordnung, oder?

Findest Du die beiden Fehler?

**Andy**

Zitat von AspirinJunkie

Die Probleme von Goto treten im Kompilat nicht mehr auf, da die Konstrukte der Ausgangssprache, welche im Maschinencode per Goto übersetzt werden, gar nicht die problematischen Konstrukte erzeugen können wie sie stattdessen mit Goto möglich wären.

Muhaaaaaa!

DER Satz hätte von mir sein können.

Wird "schön" gesetzt und ausgedruckt. Ist definitiv einer der Top10-Anwärter in der ewigen Bestenliste....

Dafür hast du dir bei unserem hoffentlich bald stattfindenden nächsten Treffen eine Runde lecker Biers verdient!

Sicherlich ist da etwas (ja, aber nur "etwas") Wahres dran. Warum nur etwas? Weil wer zum Teufel nimmt sich die bodenlose Frechheit heraus, einem gestandenen "Programmierer" vorzuschreiben, welche Sprung- bzw. Verzweigungskonstrukte er benutzen DARF und welche nicht?! Umgekehrt wird genau daraus ein Schuh! Die "Hochsprache" DARF kein GOTO benutzen, weil sie eben nicht (!!!) hauptsächlich von professionellen, will sagen erfahrenen und fach(!)kundigen Experten verwendet wird, sondern ÜBERWIEGEND (sonst macht es keinen Sinn) von unprofessionellen, unerfahrenen und nicht fachkundigen Code-zusammen-c&p-tern. Aha. Und genau für diese Zielgruppe wird dann also die bzw. eine Hochsprache "entwickelt". Jetzt wird mir so einiges klar....

Wir lassen "einfache" Konstrukte weg, damit die Deppen sich elitär gegenüber den "Kac*noob-Basic-Usern" fühlen können.

Die Verwendung bzw. Nichtverwendung von GOTO differenziert den (vermeintlichen) Könner von den "unqualifizierten" Anfängern (weil GOTO-Verwendern).

Dabei wird gerne vergessen, dass sämtliche Basic-Nachfolgesprachen ein GOTO implementiert hatten. Pascal, ja sogar das "elitäre" Turbo-Pascal hatte ein GOTO. Verdammte Axt. Nachdem das irgendwann rauskam, ging Borland mitsamt seinen anderen "Turbo"-Sprachen die Bachgasse runter. Bankrott wegen GOTO.....so kann´s geh´n.

Also besser erst gar kein GOTO in die Sprache implementieren, da sind schon ganze Dynastien von Systemhäusern dran kaputt gegangen ;o)

Btt:

Ja, ich KANN ein GOTO benutzen, muss es aber nicht. Aber das sollte in meiner Verantwortung liegen. Btw. habe ich auch in den gängigen (Makro-) Assemblern while/wend und if/then/else und Funktionen und viele überaus sinnvolle Konstrukte, welche auch in Hochsprachen verwendet werden. Aber auch ein GOTO (heisst dort Jump). Und sogar noch viel mehr, denn geschätzt 50 (!) dieser Jumps, welche abhängig von bestimmten Registern/Flags reagieren (sog conditional jumps). Um das in einer Hochsprache nachzubilden, ist einiges an Code erforderlich. Und ein "schlauer" Compiler, welcher aus dem hingetipperten Hochsprachen-Code einen mehr oder weniger schnellen/kurzen Maschinencode erstellt.

"Brauchen" tu ich das GOTO in AutoIt auch nicht.Naja, fast nicht. Ein aus dem 40 Jahre alten GW-Basic (damals noch Interpreter *träum*) entliehenes "ON ERROR GOTO" würde AutoIt vortrefflich stehen....

Da ich "nebenbei" mittlerweile viel mehr in VBA (hauptsächlich Excel) programmiere als in AutoIt, habe ich wenigstens dort mein "on error goto". Da in dieser Programmiersprache mit Hirn integriert (ansonsten ist VBA gegenüber AutoIt Lichtjahre "hintendran"), gibt es bei dessen Verwendung weder "fragwürdige Sprunganweisungen", noch Spaghetticode, und auch, selbst wenn in Funktionen verwendet, keine Speicherleaks oder gar Pufferüberläufe.

Mein Fazit zu GOTO:

Wenn ich es dann benutzen könnte, wenn ich es bräuchte, wäre ich zufrieden!

**Bitnugger**

Andy, dafür hast du dir eine glatte 1+ verdient!

In den ersten 3 Wochen meiner Programmiererlaufbahn (C 64) war wohl jeder 7. Befehl ein GOTO... und ich habe mich auch ein wenig schwer getan, darauf zu verzichten, doch weil es in einem "klugen Buch" so empfohlen wurde, habe ich es getan... und nach etwa 1 Woche habe ich das GOTO nicht mehr vermisst. Heute wüsste ich aber wohl gar nicht mehr, was ich damit anfangen sollte...

**AspirinJunkie**

Zitat von Andy

Mein Fazit zu GOTO:

Wenn ich es dann benutzen könnte, wenn ich es bräuchte, wäre ich zufrieden!

Kann man so stehen lassen denke ich.

Ansonsten ist es halt wie immer: Auch in dieser Diskussion gibt es kein Schwarz und Weiß.
Beide Seiten haben zutreffende Argumente für ihren Standpunkt für bzw. gegen Goto.
Es ist dann halt nur die Frage wie man diese gewichtet. Und eine allumfassend korrekte Gewichtung gibt es nicht.

Daher verstehe ich diese Vehemenz in der Goto-Debatte nicht wirklich.

Meine persönliche Gewichtung führt hierbei dazu dass ich mich eher der Fraktion Torvalds, Knuth, Ritchie anschließe anstatt den Dijkstra-Jüngern auch wenn ich auch ihre Argumente als nachvollziehbar erachte.

Peter S. Taler · *Ab 19-10-22 ergänzt um:*

Oscar ,

da sollten wir erstmal darüber sprechen was ein Fehler ist. Vordergründig läüft der Code. Dass Dein MSG Fenster in der "Gegend rumkugeld" ist wenig schön - wenn Du es so haben willst?

Nur leider sehe ich den Zusammenhang zu unserer GOTO Diskussion nicht. Endlosschleifen brauchen - wie man sieht kein GOTO. Abstürze habe ich hier nicht :). Ich würde es so nicht schreiben - anyway...

Aber ja sollten wir mal inen Wettbewerb daraus machen - der eine posted Code die anderen suchen den Fehler...

Gruß

Peter

**AspirinJunkie**

Zitat von Peter S. Taler

Vordergründig läüft der Code.

Ich habe hier kein AutoIt aber dürfte der Code nicht langfristig wegen einer zu hohen Rekursionstiefe den Geist aufgeben wenn man immer Next drückt?

Und GuiGetMsg sollte irgendwann auf Messages einer GUI warten obwohl alle bereits gelöscht wurden.

Tuxedo

Hier mal 2 Beispiele wie man früher Programme gemacht hat und komischerweise haben sie alle mehr oder weniger tadellos funkitoniert, gut man schrieb keine Dinger mit Tausenden von Zeilen.

Das brauchte man auch nicht. Man hat eben soviele Zeilen geschriben wie es brauchte Pasta.

Am Anfang wars eben ein bisschen ungewohnt und manchmal wars etwas fehlerhaft, aber

Fehler konnte man ausbügeln oder vermeiden. Irgendwann hat man eben angefangen zwischen den Zeilen eben 100 oder 1000 Zeilen leergelassen, damit man immer Reserven hatte, falls man etwas hinzufügen oder wglöschen musste, und so die Goto Befehle nicht alle umgeschrieben werden mussten. Also im Grunde keine unlösbaren Probleme mit den ganzen Goto's.

Endlosschleife per Goto

Zeile 1 Start

Zeile 2 Etwas bla bla dazwischen

Zeile 3 messagebox(...)

Zeile 4 Tooltip(.....)

Zeile 5 Goto 1

oder eine Funktion Handgemacht

Zeile 1 Start Funktionsaufruf Goto 6

Zeile 2 Weiter im Programm

Zeile 3 .....

Zeile 4 ......

Zeile 5 Goto 10

Zeile 6 Virtuelle Funktion

Zeile 7 $a = $b+$c

Zeile 8 Print $a

Zeile 9 Goto 2

Zeile 10 End

Heute denkt jeder hergelaufene Trottel er hätte die Weisheit mit Baggerschaufeln gefressen,

und vergisst dabei, daß schon genug andere geniale Menschen Dinge vor Hundert Jahren erfunden haben die heute immer noch eingesetzt werden. und alle denken, alles sei in der heutigen Zeit erfunden worden.

Damals(60er+70er Jahre) gab es Maschinen(Dreh-Automaten) die mittels Steckbrett und mit Endschaltern programmiert wurden und die liefen Jahrelang jeden Tag problemlos.

Die einzige und eher zweifelhafte Errungenschaft der heutigen Zeit ist die Geschwindigkeit.

Tuxedo

**AspirinJunkie**

Zitat von Tuxedo

wie man früher Programme gemacht hat und komischerweise haben sie alle mehr oder weniger tadellos funktioniert,

Es hat doch gar keiner behauptet dass die Verwendung von Goto zwangsläufig zu dysfunktionalem Code führt?

Die Kritiker von Goto bemängeln nicht die Fälle wo Goto korrekt verwendet wird (wie in deinen Beispiel) sondern allein den Umstand dass es mit Goto viel zu einfach (und damit wahrscheinlich) ist problematischen Code zu erzeugen.

Darüber hinaus sind diese Fälle selten sofort als problematisch erkennbar und erschweren damit ein Aufdecken bzw. Debugging dieser Konstellationen.

Wir könnten also noch 1000 Beispiele bringen wo Goto super funktioniert aber das geht an der Argumentation Contra-Goto vorbei.

Daher hat man nun primär zwei Fraktionen:

Einmal die Goto-Verfechter (würde mich tendenziell dieser Gruppe zugehörig fühlen) die sagen: Ich weiß wie man goto richtig verwendet und ich hab genug Disziplin das auch immer sauber umzusetzen. Manche Fälle lassen sich damit besser lösen also sollte es drin bleiben.
Auf der anderen Seite die Goto-Kritiker die sagen: Goto kann ganz böse Sachen erzeugen. Einsteiger welche noch nicht alles durchstiegen haben werden sehr wahrscheinlich in diese Fallen tappen aber auch Vollprofis können durch kleine Unaufmerksamkeiten da hineinfallen. Im Schlimmsten Fall bleibt das dann lange Zeit unentdeckt und schlummert dann solange bis es irgendwann knallt. Den Fehler dann auszumerzen ist dann enorm aufwendig da ein Debugging oftmals hierbei nicht mehr trivial ist. Diese Fallen sollte man durch Weglassen von goto daher zuschütten. Der Verlust von Funktionalität wird weitestgehend durch andere deutlich sicherere Konstrukte ausgeglichen.

Zitat von Tuxedo

Heute denkt jeder hergelaufene Trottel er hätte die Weisheit mit Baggerschaufeln gefressen,

Exakt. Aber dieses Verhalten stelle ich bei Mitgliedern beider Fraktionen fest.
Die jeweils andere Seite als Trottel zu bezeichnen, anstatt sich sachlich mit deren Argumenten auseinander zu setzen, zeugt hiervon.

Tuxedo

Und der Letzte Ausspruch bezog sich keineswegs auf diese Diskussion hier sondern betrifft eher

die heutzutage allgemein übliche Denkweise.

**Oscar**

Zitat von Peter S. Taler

Nur leider sehe ich den Zusammenhang zu unserer GOTO Diskussion nicht. Endlosschleifen brauchen - wie man sieht kein GOTO. Abstürze habe ich hier nicht

AspirinJunkie hat es schon vorweggenommen.

Das Problem bei dem Code ist, dass die Verwendung des Funktionsaufrufes als Goto-Ersatz eben nicht (dauerhaft) funktioniert.

Bei jedem Funktionsaufruf wird die Rücksprungadresse auf den Stack abgelegt und erst dann wird die Funktion aufgerufen. Erfolgt kein Rücksprung aus der Funktion füllt sich der Stack immer weiter, bis AutoIt schließlich einen Error auswirft (stack overflow).

Der zweite Fehler ist der, dass in Zeile 23 die Funktion "Eingabe" aufgerufen wird, aber danach ein ExitLoop oder Return fehlt, denn das Return beim Schliessen des Fenster springt halt zu der letzten Adresse auf dem Stack zurück und das ist an die Stelle nach Zeile 23 und somit hängt das Programm in der Endlosschleife fest.

Wenn ein Funktionsaufruf genau das gleiche wäre, wie ein Goto, dann würde das Script problemlos funktionieren.

Das ist aber nicht der Fall, eben weil man einen Funktionsaufruf auch wieder (mit Return) beenden muss, sodass man an die aufrufende Stelle zurückkehrt.

**Oscar**

Zitat von Tuxedo

Irgendwann hat man eben angefangen zwischen den Zeilen eben 100 oder 1000 Zeilen leergelassen, damit man immer Reserven hatte, falls man etwas hinzufügen oder wglöschen musste

Ohje, das sieht sehr nach C64-Basic aus.

Also wenn schon Goto, dann doch bitte Goto mit Label und nicht mit Zeilennummern.