goto-befehl in delphi?

[toredo]

hay,

eigentlich frage ich mich das schon einige zeit, gibt es in delphi nicht auch so nen goto-befehl wie bei batch?
wäre vielleicht ab und zu vorteilhaft, kA.


mfG toredo

[arbu man]

Delphi-Quellcode:

goto

und

Delphi-Quellcode:

label

gibt es in delphi

[mkinzler]

Ein Grund für die Entwicklung der Sprache Pascal, war der Goto-Befehl. Bei sauberer Entwicklung kann man problemlos auf ihn verzichten. Bei der batchprogrammierung benutzt man ihn ja nur aus Ermangelung strukturierter Sprachelementen.

[Oxmyx]

Es gibt einige Ausnahmen, in denen der Goto-Befehl hilfreich sein kann. Zum Beispiel, um aus verschachtelten Schleifen herauszukommen, wenn eine bestimmte Bedingung eingetreten ist.

[mkinzler]

Auch dazu braucht man keinen goto-Befehl.

[Zacherl]

Dazu kann man nämlich Break benutzen, wenn man den Code richtig strukturiert hat.

[3_of_8]

Gotos sind verpönt. Und das nicht ohne Grund - sie erzeugen unübersichtlichen und auch teilweise fehleranfälligen Code.

Sowas konnte man zu BASIC Zeiten vielleicht machen, aber heute ist das ein absolut schlechter Programmierstil.

[lizardking]

Zitat:

Zitat von Oxmyx

Es gibt einige Ausnahmen, in denen der Goto-Befehl hilfreich sein kann. Zum Beispiel, um aus verschachtelten Schleifen herauszukommen, wenn eine bestimmte Bedingung eingetreten ist.

Ja nee, is klar. Man kann natuerlich auch einfach die verschachtelten Schleifen in ein try...except packen und eine Exception werfen, wenn eine bestimmte Bedingung erfuellt ist. Funktioniert auch - :rolleyes:

Nur wozu gibt es verschiedene Schleifentypen? Eine for-Schleife ist nun einmal darauf ausgelegt komplett durchlaufen zu werden (sonst haette sie sicherlich eine Abbruchbedingung, wie z.B. in C++ oder Java).

[Oxmyx]

Nein, Break geht eben nicht, wenn man auf die Einführung einer zusätzlichen Variable verzichten will. Delphi kennt eben kein Konstrukt wie "Break 2", "Break 3", etc.

[Oxmyx]

Ich habe bis jetzt in den vielen hunderttausend Programmzeilen, die ich bislang in Delphi geschrieben habe, genau ein Mal das Goto-Konstrukt verwendet, weil es in der Situation völlig sinnvoll war. Alles andere hätte den Code unübersichtlicher und unklarer gemacht. So ein pawlowscher Ablehnungsreflex gegen ein Sprachfeature von Delphi ist nicht gerade sehr überlegt.

[Zacherl]

Break geht eben doch: Aufgerufen in einer Schleife bricht es diese an der Aufrufstelle ab.

Beispiel:

Delphi-Quellcode:

var
  i: integer;
begin
  for i := 0 to 10 do
  begin
    if i = 5 then
      break;
  end;
  ShowMessage(IntToStr(i)); //Es wird 5 ausgegeben, da dort die Schleife abbricht
end;

Florian

[Oxmyx]

Zitat:

Zitat von Florian Bernd

Break geht eben doch: Aufgerufen in einer Schleife bricht es diese an der Aufrufstelle ab.

Sagte ich schon, dass ich von verschachtelten Schleifen rede? Ja, sagte ich.

[xaromz]

Hallo,

Zitat:

Zitat von Florian Bernd

Break geht eben doch: Aufgerufen in einer Schleife bricht es diese an der Aufrufstelle ab.

wie oxmyx schon schrieb, was machst Du, wenn Du aus zwei (drei...) Schleifen springen willst? Mit Break bleibt Dir nur, ein Flag zu setzen, gefolgt von einem Break, in der übergeordneten Schleife das Flag untersuchen -> Break...
Machmal ist ein goto schon in Ordnung. Man muss nur wissen wann.

Gruß
xaromz

[Zacherl]

Es geht auch mit verschachtelten Schleifen, sogar ohne ein extra Flag zu setzen:

Delphi-Quellcode:

var 
  i, i2, i3: integer;
begin
  for i := 0 to 10 do
  begin
    for i2 := 0 to 20 do
    begin
      for i3 := 0 to 30 do
      begin
        if i3 = 15 then
          break;
      end;
      if (i3 = 15) and (i2 = 10) then
        break;
    end;
    if (i3 = 15) and (i2 = 10) and (i = 5) then
      break;
  end;
end;

Wieso denn nicht einfach die Zählervariable verwenden, die sowieso in(de)crementiert wird?

Florian

[xaromz]

Hallo,

Zitat:

Zitat von Florian Bernd

Es geht auch mit verschachtelten Schleifen, sogar ohne ein extra Flag zu setzen:
...

Und wo ist das übersichtlicher/weniger fehlerträchtig als 1(!) goto? Mit einem goto spare ich mir mehrere Abfragen und der Code wird wesentlich übersichtlicher. Nur weil einem jemand mal erzählt hat, dass etwas schlecht ist, muss man es noch lange nicht glauben, ohne es zu hinterfragen.

Manchmal zweifle ich echt an der Menschheit :? .

Gruß
xaromz

[Oxmyx]

Zitat:

Zitat von Florian Bernd

Es geht auch mit verschachtelten Schleifen, sogar ohne ein extra Flag zu setzen:
[...]

Wieso denn nicht einfach die Zählervariable verwenden, die sowieso in(de)crementiert wird?

Florian

Na das ist ja mal übersichtlich, besonders wenn die Bedingung komplizierter formuliert ist. ;)
Und da willst du mir erzählen, dass das Goto-Konstrukt unübersichtlich wäre?

[mkinzler]

Man könnte auch exit nehmen.

[3_of_8]

Das springt aus der ganzen Subroutine raus, was in vielen Fällen nicht erwünscht ist.

[xaromz]

Hallo,

Zitat:

Zitat von mkinzler

Man könnte auch exit nehmen.

damit springt man aber komplett aus der Routine. Das ist nicht immer gewünscht.

Gruß
xaromz

[Zacherl]

Zitat:

Zitat von xaromz

Hallo,

Zitat:

Zitat von Florian Bernd

Es geht auch mit verschachtelten Schleifen, sogar ohne ein extra Flag zu setzen:
...

Und wo ist das übersichtlicher/weniger fehlerträchtig als 1(!) goto? Mit einem goto spare ich mir mehrere Abfragen und der Code wird wesentlich übersichtlicher. Nur weil einem jemand mal erzählt hat, dass etwas schlecht ist, muss man es noch lange nicht glauben, ohne es zu hinterfragen.

Tue ich nicht! Ich hatte auch nie gesagt, dass meine Variante besser ist :mrgreen: Nur wenn jemand sagt: "das ist nicht möglich ohne extra Flag" ... wieso ihm nicht zeigen, dass es doch möglich ist?

Zitat:

Zitat von Oxmyx

Und da willst du mir erzählen, dass das Goto-Konstrukt unübersichtlich wäre?

Auch dies habe ich nie behauptet.

Florian

[mkinzler]

Noch ne möglichkeit wäre das Abbrechen in die Schleifenbedingung aufzunehmen.

[Nicolai1234]

Zitat:

Zitat von Florian Bernd

Zitat:

Zitat von xaromz

Hallo,

Zitat:

Zitat von Florian Bernd

Es geht auch mit verschachtelten Schleifen, sogar ohne ein extra Flag zu setzen:
...

Und wo ist das übersichtlicher/weniger fehlerträchtig als 1(!) goto? Mit einem goto spare ich mir mehrere Abfragen und der Code wird wesentlich übersichtlicher. Nur weil einem jemand mal erzählt hat, dass etwas schlecht ist, muss man es noch lange nicht glauben, ohne es zu hinterfragen.

Tue ich nicht! Ich hatte auch nie gesagt, dass meine Variante besser ist :mrgreen: Nur wenn jemand sagt: "das ist nicht möglich ohne extra Flag" ... wieso ihm nicht zeigen, dass es doch möglich ist?

In dem Fall aber nur mit 3x break. Ich denke, es ging darum, dass man deutlich mehr als einen kleinen Befehl braucht, um das umzusetzen.

[Zacherl]

Zitat:

Zitat von mkinzler

Noch ne möglichkeit wäre das Abbrechen in die Schleifenbedingung aufzunehmen.

Wie meinst du das? Einfach i auf den Wert setzen, bei dem die Schleife rausspringt? Geht das überhaupt?

//Edit: Nein, so geht es nicht.

[mkinzler]

Zitat:

Wie meinst du das? Einfach i auf den Wert setzen, bei dem die Schleife rausspringt? Geht das überhaupt?

Nein Ich meinte Bedingung erweitern

Delphi-Quellcode:

<bedingung> or <abbruchbedingung>

[Nicolai1234]

Zitat:

Zitat von mkinzler

Zitat:

Wie meinst du das? Einfach i auf den Wert setzen, bei dem die Schleife rausspringt? Geht das überhaupt?

Nein Ich meinte Bedingung erweitern

Delphi-Quellcode:

<bedingung> or <abbruchbedingung>

Aber nicht in einer for Schleife, oder?

[mkinzler]

Eine Forschleife sollte man auch nicht abbrechen müssen, sonst würde ich halt ne while-Schleife nehmen mit den 2 Bedingungen.

[Zacherl]

Zitat:

Zitat von Nicolai1605

Zitat:

Zitat von mkinzler

Zitat:

Wie meinst du das? Einfach i auf den Wert setzen, bei dem die Schleife rausspringt? Geht das überhaupt?

Nein Ich meinte Bedingung erweitern

Delphi-Quellcode:

<bedingung> or <abbruchbedingung>

Aber nicht in einer for Schleife, oder?

Irgendwie wüsste ich nicht, wie das dort gehen soll :gruebel: Außer man macht es ähnlich wie in meinem Beispielcode, in dem ich die Zählervariablen abgefragt habe.

Florian

[Hansa]

Zitat:

Zitat von Oxmyx

Ich habe bis jetzt in den vielen hunderttausend Programmzeilen, die ich bislang in Delphi geschrieben habe, genau ein Mal das Goto-Konstrukt verwendet

Das zeigt, wie unsinnig das Ganze war / ist. Das eine mal ist auch unsinnig. 8) Die GOTO Konzepte gehen zurück in die Zeit nach dem 2. Weltkrieg. Also, was soll die Frage ?

[Real_Thunder]

So nun gebe ich auch mal meinen Senf dazu

Ich habe vor langer... sehr langer zeit auch mit BASIC Programmiert, und zu anfang war das goto noch recht hilfreich....
Doch dies ist auch ein e Falle....

mal zur erklärung.. so ein oder 2 gotos zu benutzen kein problem.. das stört die übersichtlichkeit nicht wirklich.

nun das Aber:

Wiele die gerae mit dem Programmieren angefangen haben und nicht von allen seiten zu hören bekommen das goto "Böse" ist..
benutzen es viel zu häufig...

dann kommen anschließend, sehr viele verschachtelungen raus..

Moderne Programmiersprachen, arbeiten immernoch mit einer art GOTO bzw GOSUB ... doch weil diese nach ablauf immer wieder zur Hauptroutine Springen,
bleibt der quellcode sauberer.....

Also mal die Zusammenfassung...

GOTO wenige male Benutzen... KEIN Problem

goto in goto in goto .... Wird schnell total unübersichtlich

Also jedem der nicht schon Lange programmiert.. das goto ausreden

und die menschen die schon länger programmieren, wissen wann es sinnvoll ist...



so, und wenn wir schonmal dabei sind... schleife n schneife in schlefe ist von vorne rein nicht am saubersten programmamiert, wenn man beabsichtigen will aus der letzten schleife komplett aus dem scheifengerüst zu springen

[Luckie]

Zitat:

Zitat von Hansa

Das zeigt, wie unsinnig das Ganze war / ist. Das eine mal ist auch unsinnig. 8) Die GOTO Konzepte gehen zurück in die Zeit nach dem 2. Weltkrieg. Also, was soll die Frage ?

Wie einfach wird doch die Welt, wenn man alles schwart/weiß sehen kann. :? Wie schon gesagt, in manchen Fällen macht ein goto schon Sinn. Und was ist ein Exit oder Break, wenn nicht ein goto?

[Oxmyx]

Zitat:

Zitat von Hansa

Das zeigt, wie unsinnig das Ganze war / ist. Das eine mal ist auch unsinnig. 8) Die GOTO Konzepte gehen zurück in die Zeit nach dem 2. Weltkrieg. Also, was soll die Frage ?

Wenn auf sachlicher Ebene nichts mehr hilft, muss man sich wohl in solche Phrasen stürzen. Wie schon in Beispielen gezeigt, kann Goto helfen, unübersichtliche Bedingungen zu entzerren und Kontrollflags zu vermeiden. Ich habe noch keinen einzigen sachlichen Grund dafür gelesen, was genau daran schlecht ist. Stattdessen lese ich nur Phrasendrescherei.

[omata]

Meine Güte,
was für ein überflüssiger Thread.

folgende Befehle sind überflüssig: exit, goto, break das sind Befehle, die nicht zu einer strukturierten Programmierung gehören. Das ist nun mal so. da kommt man nicht drum herum. Natürlich kann man alles irgendwie hinwurschteln. Aber warum? warum nicht gleich ordentlich und strukturiert programmieren?
Der Computer führt nichts anderes als Sprungbefehle aus, aber eben auf Assemblerebene. Wenn man also die nicht strukturierten Befehle benutzen möchte, sollte man in Assembler programmieren, dann braucht man auch keine höhere Programmiersprache wie Delphi.

So, jetzt könnt ihr wieder weiter rumnörgeln. Ich kann nur wieder holen, denke nach und programmiere überlegt, dann werden auch keine Sprungbefehle wie exit, break und goto benötigt. Man braucht sie nicht und fertig.

Gruss
Thorsten

[Luckie]

Zitat:

Zitat von omata

folgende Befehle sind überflüssig: exit, goto, break

Und was wenn ich eine Prozedur habe, bei der ich an einem betsimmten Punkt nicht weitermachen kann? OK, einer mag ja noch gehen. Aber wie sieht es bei drei oder mehr aus? Find dich da mal in den verschachtelten ifs und elses zurecht.

Code:

if Belegnummer = 0 then
  exit
if Belegdatum = 0 then
  exit
if x = 0 then
  exit
if y = 0 then
  exit

Mach das mal mit ifs. Viel Spass, wenn du nach einem halben Jahr den Code warten musst. Mit dem Exits entspricht es genmau dem Programmablaufplan.

[omata]

Das ist negative Logik. So sollte man nicht programmieren. Wie wäre es mit positiver Logik?

Wie gesagt exit ist nicht nötig und blödsinn.

Gruss
Thorsten

[Dax]

Zitat:

Zitat von Luckie

Code:

if Belegnummer = 0 then
  exit
if Belegdatum = 0 then
  exit
if x = 0 then
  exit
if y = 0 then
  exit

Delphi-Quellcode:

if not ((Belegnummer = 0) or (Belegdatum = 0) or (x = 0) or (y = 0)) then
begin
  ...
end;

:?:

[Luckie]

Ging nicht, weil immer eine andere Fehlermeldung kommen musste.

[Oxmyx]

Zitat:

Zitat von omata

Das ist negative Logik. So sollte man nicht programmieren. Wie wäre es mit positiver Logik?

Wie gesagt exit ist nicht nötig und blödsinn.

Gruss
Thorsten

Du hast eine Funktion, der ein oder mehrere Parameter übergeben werden. Falls die übergebenen Parameter nicht innerhalb eines gewissen Gültigkeitsbereichs liegen, kann die Funktion nicht arbeiten und muss gleich wieder abgebrochen werden. Wie machst du das denn?

[JasonDX]

Zitat:

Zitat von omata

folgende Befehle sind überflüssig: exit, goto, break das sind Befehle, die nicht zu einer strukturierten Programmierung gehören. Das ist nun mal so. da kommt man nicht drum herum. Natürlich kann man alles irgendwie hinwurschteln. Aber warum? warum nicht gleich ordentlich und strukturiert programmieren?
Der Computer führt nichts anderes als Sprungbefehle aus, aber eben auf Assemblerebene. Wenn man also die nicht strukturierten Befehle benutzen möchte, sollte man in Assembler programmieren, dann braucht man auch keine höhere Programmiersprache wie Delphi.

So, jetzt könnt ihr wieder weiter rumnörgeln. Ich kann nur wieder holen, denke nach und programmiere überlegt, dann werden auch keine Sprungbefehle wie exit, break und goto benötigt. Man braucht sie nicht und fertig.

Wenn du keine Sprungbefehle in Hochsprachen verwenden willst, frag ich mich, wie du ohne diese eine switch-Anweisung in C# überleben willst :tongue:

Meine Meinung ist folgende: Eine generelle Behauptung "dieser Befehl/Anweisung ist überflüssig/sinnlos" ist nicht haltbar. Wenn sie überflüssig und sinnlos ist, hätte sie nicht über 30 Jahre überlebt.
Ein Goto ist natürlich immer sehr umstritten. Es führt durch falsche Verwendung (weitaus leichter als ein break oder ein exit) zu unleserlichem Code - und ist gerade deswegen sehr verpöhnt. Das bedeutet allerdings nicht, dass es an manchen Plätzen keine Berechtigung hat.
Natürlich kann man auch Code, Prozeduren, Schleifen ect. ohne Sprungbefehle schreiben, ich kann eine Prozedur auch mit einer einzigen Variable implementieren, aber bestimmte Befehle und Anweisungen existieren, um mir als Programmierer das Leben zu erleichtern. Und ich sehe keinen Grund, mir extra Arbeit aufzudrücken zu müssen, wenns auch einfacher mit dem selben Ergebnis geht.

greetz
Mike

[Luckie]

Zitat:

Zitat von omata

Das ist negative Logik. So sollte man nicht programmieren. Wie wäre es mit positiver Logik?

Code:

if Belegnummer <> 0 then
begin
  if BelegDatum <> 0 then
  begin
    if x <> 0 then
    begin
     if y <> 0 then
     begin
     end
     else
       Fehlermeldung
    end
    else
      Fehlermeldung
  end
  else
    Fehlermeldung;
end
else
  Fehlermeldung

Sehr übersichtlich, wenn in jedem Block noch 10 Zeilen Code stehen :? Wenn ich das Exit im Code sehe, dann weiß ich, dass ich mir den Rest nicht mehr angucken muss und muss mir nicht erst 30 Zeilen tiefer das zugehörige else suchen, um zu gucken, was stattdessen passiert.

[omata]

Zitat:

Zitat von Luckie

Ging nicht, weil immer eine andere Fehlermeldung kommen musste.

Für solche Fälle gibt es Exceptions.

Zitat:

Zitat von Oxmyx

Du hast eine Funktion, der ein oder mehrere Parameter übergeben werden. Falls die übergebenen Parameter nicht innerhalb eines gewissen Gültigkeitsbereichs liegen, kann die Funktion nicht arbeiten und muss gleich wieder abgebrochen werden. Wie machst du das denn?

Da überlegt man sich den positiven Fall (nicht den Negativen), hab ich ja oben schon geschrieben.

Zitat:

Zitat von JasonDX

Wenn du keine Sprungbefehle in Hochsprachen verwenden willst, frag ich mich, wie du ohne diese eine switch-Anweisung in C# überleben willst :tongue:

Wir reden hier von Delphi. Wenn eine Programmiersprache keine Möglichkeiten für eine strukturierte Lösung bietet, dann bleibt einem wohl nichts übrig, als unstrukturiert zu programmieren.

Gruss
Thorsten