Was haltet ihr von Goto

[KatSeiko]

Also wer Goto verwendet, holt sich damit eigentlich nur zwei Dinge ins Boot: Bugs und Inkompatibilität.

Dass Stargate in Spielen GOTO verwendet, habe ich schon geahnt, denn seine Spiele funktionieren zwar unter XP und 32bit, aber unter 64bit sind sie ein Rohrkrepierer. (Sorry, aber es ist so... Schade, denn unter 32bit machen sie eigentlich Laune...)
Andere Spiele hab ich noch nicht getestet, aber ich kann mir vorstellen, dass das auch anderen so gehen wird.

[STARGÅTE]

Was hat GoTo mit 32bit/64bit zu tun ?

Eine Sprungmarke ist unter 32Bit kompilierung nun mal 32Bit, das kann ich ja nun nicht ändern

Außerdem wäre nach deiner Theorie dann auch eine DataSection "verboten", in der es ja auch Sprungmarken gibt ...

GoTo hat damit meiner Meinung nach garnix zu tun ...

[Thorium]

Was hat GoTo mit 32bit/64bit zu tun ?

Garnix, der gute Mann hat einfach nur totalen Käse erzählt. 32Bit Programme laufen unter einem 64Bit System im 32Bit Kompatiblitätsmodus, der 32Bit Pointer unterstützt.

Zumal der kompilierte Code sowieso tausende von GoTo's hat, ob man die nun in der Programmierung verwand hat oder nicht. Ein GoTo ist auch nur ein Jump. Eine der häufigsten Assembleranweisungen.

[hardfalcon]

Goto braucht eigentlich kein Mensch, man kann jeden Code auch so (um)strukturieren, dass er ohne Goto auskommt.
Goto bringt nur Spaghetti-Code mit sich, zumindest Einsteiger sollten Komplett die Finger davon lassen. IMHO hat es gar nix in einer Programmiersprache zu Suchen, Fred hätte dieses Konstrukt aus PureBasic einfach komplett raushalten sollen. Die Leuten, die WIRKLICH wissen was sie tun, und glauben, es unbedingt zu brauchen, hätten dann ja immer noch !JMP nehmen können.

[Ligatur]

Wird von mir ganz sparsam genutzt und zwar in der Tat meist dann wenn eine Mehrfachschleife verlassen werden muß, andere Fälle gibts kaum.

Das ist verwunderlich weil Goto gerade zum Verlassen von Schleifen absolut ungeeignet ist da bei Schleifen Werte auf den Stack gelegt werden die nur beim regulären Verlassen der Schleife wieder ordnungsgemäß entfernt werden. Beim Verlassen mit Goto wird somit der Stack durcheinandergebracht was das Programm ganz schnell instabil macht, bei Verwendung in Prozeduren besonders.

Goto ist sicherlich nicht das Werk des Teufels und auch nicht böse, sollte aber weniger tendenziös ausgedrückt schon vermieden werden, vor allem wenn man nicht weiß was man damit anrichten kann.

[KatSeiko]

Okay... Dann erklärt mir doch mal bitte folgendes: Dune 2077 funktioniert auf meinem Laptop hervorragend. Der ist auf XP 32bit. Auf meinem virtuellen PC ebenfalls, der ist Vista 32bit. Auf meinem Arbeitsrechner (auf dem ich übrigens auch mit PB programmiere) aber funktioniert es einfach nicht. Auch nicht mit dem WOW64-Kram, von dem Thorium erzählt, wird es nicht besser...

Das mit der DataSection ist ansich nicht das Problem, aber irgendwie ist das Problem, dass die Größe der Sprungmarke verschieden ist (.l gegen .q)... Zugegeben - als eine Sprungmarke noch die Größe eines Bytes hatte und auf einmal ein Integer groß wurde, war es auch schwer, sich einzugewöhnen... Aber ich bin zuversichtlich, dass auch diese Phase hier vorbei geht. Mit Quads dürft ihr gern weiter GoTo verwenden (tut übrigens auf Win32 nicht weh), aber mit Integers sorgt das unter gewissen Umständen eben für einen Pufferüberlauf und damit für einen Absturz.
Bei Schleifen und Procedures sollte man mit dem GoTo besonders vorsichtig sein - das Aufrufen von Procedure packt die Daten der Rücksprungmarke in den Stack, was bei mehrmaligem Verlassen zu Problemen führen kann. Repeat-Until geht noch, aber While- For-Next und einige andere Konstrukte sorgen auf die Art zu ziemlich unschönen Ergebnissen - gern auch zum Crash.

Der Kompatibilitätsmodus arbeitet übrigens dann nicht, wenn Du zum Beispiel die Größe Deiner Daten in Deinem Programm ausgerechnet hast (z.B. size.l = ?marke2 - ?marke1). In dem Fall sollte man der Größe schon ein paar Bit mehr gönnen. (und mir eins abgeben )

[PMV]

Auf 32Bit ist alles 32Bit ... bis auf die großen Variablentypen ... weil das
OS und seine Programme auf 32Bit kompiliert werden. Wenn der Emulator
nicht in der Lage ist, auf der 64Bit Maschine die 32Bit aus zu führen, was
bringt dich zur festen Ansicht, dass es an den Sprungmarken liegen soll,
die, wie schon erwähnt ... als ASM-Output genau das selbe ergeben wie
z.B. BREAKs oder CONTINUEs ...?

Ich mein, ich kenn mich mit ASM und CPU-Architekturen auch nicht wirklich
aus ... aber was hat das mit den größen der Sprungmarken zu tun? Durch
die Emulation sollte das 32Bit Programm genau so funktionieren, wie auf
einer 32Bit-Maschine, tut es das nicht ... liegt es am Emulator.

MFG PMV

[Captn. Jinguji]

@ DrFalo
Seit wann kennt man seine Rekursionstiefe nicht? Kann mir grade keinen derartigen Fall vorstellen...

Öhmmm rekursives Abklappern von Filesystemen z.B. ?

Aber ich benutze andererseits auch nie GOTO, ist mir zu unübersichtlich.

Das macht man aber mit einer Prozedur und keiner Schleife. Und wo da
nen Goto hin kommen könnte ist mir auch schleierhaft.
MFG PMV

Wer hat denn unbedingt von Schleifen gesprochen ?
Ich habe mich zu Rekursionstiefen geäussert
Wie soll überhaupt Rekursion "mit Schleifen" ermacht werden ?
Also OHNE Prozeduraufruf?

[THEEX]

Ich würd sagen, folgendes trifft sehr genau den Punkt. Das entspricht sehr genau meiner Meinung zu Goto, ohne das ich es vorher kannte...:
http://de.wikipedia.org/wiki/Sprunganweisung

[Kaeru Gaman]

interessanter Satz in dem Artikel:

Eine weniger kritisierte Variante des Goto-Befehls ist das vorzeitige Verlassen eines Unterprogramms durch einen return-Befehl oder das Abbrechen einer Schleife durch einen break-Befehl. Trotzdem gilt es allgemein als guter Programmierstil, wenn ein Block einen Einsprungpunkt und einen Ausstiegspunkt hat.

meine Rede seit Siebzehnhundertleipzig.....

und @topic

in dem Artikel wird lediglich eine differenzierte Sichtweise vermittelt.
da steht aber nirgens, dass man Anfängern die verwendung von Goto empfehlen sollte,
damit sie erstmal richtig Müll produzieren bevor sie anständig Programmieren lernen...