Kann "goto" wieder "in" werden?

[tenim]

spaghetticode ist nur eine mögliche auswirkung und auch nur wenn man goto exessiv benutzt. ich gehe von einmaliger nutzung im notfall aus.

[PeterTheMaster]

int i = 1;
for (;i < 1000000, array[i] != 'A' ; ++i) ;

wann wird sich endlich rumgesprochen haben, wie der 'op,' funktioniert?
hier ist ein && gemeint, sonst wirds wohl irgendwann ne schutzverletzung geben.

edit: zum thema: ich hatte noch nie wirklich das beduerfnis, ein goto zu verwenden. koennts mir hoechstens vorstellen, wenn man aus einer inneren schleife raushuepfen will. aber meist tut man eh die suche oder was immer diese beiden schleifen tun in eine extra funktion, und dann tuts auch ein return.

[ Dieser Beitrag wurde am 02.12.2002 um 14:20 Uhr von PeterTheMaster editiert. ]

[Snakey]

Im Assembler-Code und später Maschinencode werden doch sowieso gotos verwendet, ausserdem lässt sich leicht beweisen, dass man mit gotos dasselbe machen kann wie mit while oder loop-Schleifen.
Es sieht ohne zwar besser aus, kann aber manchmal ohne auch etwas lästig sein !

[Bashar]

@Snakey:

Man vermeidet goto nicht, wie du zu glauben scheinst, weil es zuwenig kann, sondern weil es zuviel kann.

[Marc++us]

Original erstellt von PeterTheMaster:
aber meist tut man eh die suche oder was immer diese beiden schleifen tun in eine extra funktion, und dann tuts auch ein return.

Sicherlich, aber genau das ist (für C- und C++-Entwickler) der interessante Punkt:

Wer sowas schreibt:

void func()
{
   for (...)
   {
      if (something)
         return;
      ...
   }
}

verwendet ein goto. Daran beißt die Maus keinen Faden ab:

void func()
{
   for (...)
   {
      if (something)
         goto endmark;
      ...
   }
endmark:
}

Ist ja auch ok - das bringt oftmals Performance und ist typischer und akzeptierter C-Stil.

Lustig wird's nur dann, wenn jemand return in Schleifen (oder break) verwendet, aber gleichzeitig zum Kreuzzug gegen goto ausreitet.

[rüdiger]

das ist aber das Problem, dass sich die Sprungmarke auch überschneiden könnte, was beim compilieren zu merkwürdigen Fehlermeldungen führen kann

[kartoffelsack]

Das Problem beim goto ist aber nicht die Anwendung die einem break, return oder continue entspricht, welche sich darauf beschränkt, ein paar Zeilen im strukturierten Code zu überspringen (also zur weiter runter im Aufrufstack zu gehn), sondern dass ich mit goto irgendwohin an ne ganz andere Stelle im Code in ner ganz anderen Funktion springen kann. Hier wird der Programmfluss, wie er lt. strukturiertem Programmierparadigma sein sollte, völlig unterlaufen. Noch nicht mal mit nem throw kann ich komplett woanders hinspringen.

Klar, wenn ich vorsichtig damit bin, kann ich goto in diesen Fällen einsetzen. Aber ein return garantiert mir halt, dass ich ans Ende der Funktion springe und von da aus in die aufrufende Funktion zurückkehre, wo sicher aller lokalen Variablen initialisiert sind, und nicht versehentlich sonstwohin.

Man kann auch mit ner strukturieren Programmiersprache objektorientiert programmieren. Aber warum sollte man nicht gleich die Sprachmittel einer objektorientierten Sprache nehmen? Dasselbe ist mit goto. Klar kann man ganz ohne Funktionen funktional programmieren und mit gotos rumstpringen. Aber warum?
Außer wenns um wirklich hochoptimierten Code geht, wird man ein goto in einem C/C++-Programm immer und ohne Verrenkungen durch was anderes ersetzen können. Wenn nicht, siehts mir schwer nach nem Design-Fehler aus. Aber natürlich lässt sich jede Regel durch eine Ausnahme bestätigen.

[japro]

while if for etc. sind doch sowieso nur spezialisierungen von gotos. wenn man solche spezialisierungen schon hat dann sollte man sie auch benutzen.. aber sobald man dadurch einen murks erzeugen muss sollte man die benutzung von sochen höheren konstrukten nicht erzwingen...

[Marc++us]

Original erstellt von kartoffelsack:
sondern dass ich mit goto irgendwohin an ne ganz andere Stelle im Code in ner ganz anderen Funktion springen kann.

In BASIC vielleicht...

Das ist doch der Gag, das Goto von dem im Zusammenhang mit dem berüchtigten Spaghetti-Code die Rede ist (Sprünge an beliebige Programmzeilen innerhalb des gesamten Codekomplexes) hat mit dem Schlüsselwort goto der Sprachen C und C++ nur geringe Gemeinsamkeiten. Deswegen ist die Anführung von Argumenten gegen das BASIC-Goto im Zusammenhang mit dem C-goto nur mäßig sinnvoll.

[kartoffelsack]

@marc++us

Wenn das so ist, nehm ich alles zurück und behaupte das Gegenteil. Hab mich leider nie mit dem C/C++-goto beschäftigt und pauschal mein wissen aus anderen Sprachen drauf angewendet.

Wieder was gelernt

[Daniel E.]

Original erstellt von Marc++us:
**```cpp
[...]if (something)
goto endmark;
...
}
endmark:
}

  
  
Ist ja auch ok - das bringt oftmals Performance und ist typischer und akzeptierter C-Stil.**

Naja, akzektiert wird's wenn Du einen Befehl, z.B. ';' nach 'endmark:' plazierst :). Aber sonst ein schönes Anwendungsbeispiel für goto.

Das einzige Problem im Zusammenhang mit der Verwendung von goto ist, dass es das formale Verifizieren von Programmen schwierig (oder unmöglich?) macht. Das sollte aber in der Praxis kein Problem sein :).

Kartoffelsack: Natürlich _braucht_ man kein goto. Man kann sogar beweisen, dass man es nicht braucht. Das sagt über den praktischen Nutzen ziemlich nichts aus.

[ Dieser Beitrag wurde am 02.12.2002 um 19:50 Uhr von Daniel E. editiert. ]

[Bashar]

Hat eine Turing-Maschine goto? Eben.

[Daniel E.]

Wer spricht von Turing-Maschinen? Eben.

[niemand]

´´

[Bashar]

Du. Implizit.

[Jester]

An Turing-Máschinen mußte ich schon denken, als Gregor postuliert hat, eine Programmiersprache müsse nur abstrakt genug sein, dann brauche sie auch keine Plattform.

[DocJunioR]

GoTo End

Das GoTo ist ein Verstoß gegen die strukturierte Programmierung.

Lt. dieser hat ein Programm(teil) genau einen eingan und einen Ausgang.
mit dem Goto ist ein solcher Progammteil jedoch unwirksam, da man überall hin springen kann.

Das GoTo bewegt den ProgramPointer genau an die Stelle, wo man ihn haben will.
Es gibt dabei keinen eindeutigen Weg mehr zurück!

Der Call in Funktionen merkt sich auf dme Stack die Adresse, von der aus die Funktion aufgerufen wurde. Nach der Abarbeitung der Funktion wird zurück gesprungen.

Soviel zum Bekannten.
Man kann sich nun denken, was passiert, wenn man ausversehen mal ein goto falsch setzt. Es kommt zu Endlosschleifen, völlig wirrsinnigen Daten und unnötigen Programmabstürzen.

Außerdem: Weiß jemand, wie aufwendig es ist, Code zu verstehen, der nur aus GoTo's besteht? Ich möchte so ein Programm nicht warten müssen oder noch einmal anfassen, nach dem ich selbst es ein halbes Jahr zuvor geschrieben habe..

cYa
DjR

End:

[Bashar]

1. goto verwenden wenn es paßt ist was anderes als nur goto zu verwenden
2. strukturierte Programmierung ist out. Nicht dass ihre Prinzipien keinen mehr interessieren, aber heute ist nur noch eine gefilterte Version davon übrig, sonst dürftest du kein break oder continue benutzen, kein return (ausser am lexikalischen Ende der Funktion) und keine Exceptions.

[DocJunioR]

Klar, heutzutage ist die Objektorientierung eher in. Allerdings gelten hier teilweise noch schärfere Regeln.
Ein break in einer CASE-Anweisung ist IMHO kein Verstoß gehen die Strukturierte Programmierung.
Ich persönlich habe mir das GoTo abgewöhnt und würde das auf jeden Fall anraten, da man einfach zuviel Mist damit bauen kann.
Allerdings ist der Programmierstil wie eine zweite Handschrift. Er wandelt sich im Laufe der Zeit, ist aber immer erkennbar..

cYa
DjR

[Bashar]

Original erstellt von <DocJunioR>:
Ein break in einer CASE-Anweisung ist IMHO kein Verstoß gehen die Strukturierte Programmierung.

Stimmt, ich meinte auch mit break eher vorzeitigen Abbruch von Schleifen. break in switch ist halt eine Eigenart von C -- dafür wär es unstrukturiert, das break wegzulassen.

Anfängern würde ich grundsätzlich empfehlen, goto nicht zu verwenden. Fortgeschrittene sollten aber im Hinterkopf als primäres Ziel die Klarheit haben: Wird ein Konstrukt durch goto klarer als mit einer Alibi-Schleife, spricht nichts dagegen.