break in verschachtelten loops

_matze

Ich hatte mal einen Fall in dieser Art:

int func() {
  for(...) {
    for(...) {
      for(...) {
        if(...) {
          for(...) {
            if(...) {
              //...
            } else {
              goto raushierverdammtnochmal;
            }
          }
        }
      }
    }
  }
  raushierverdammtnochmal:
  //eine abschließende Anweisung
}

Na ja, irgendwie so. Hier finde ich das goto jedenfalls einfach vertretbar. Es schadet jedenfalls nicht der Übersicht, passt ja alles locker auf eine Seite. Ich spare mir das bilden einer zweiten Funktion, um das Ausführen der abschließenden Anweisung zu gewährleisten (wäre zwar eine Möglichkeit, aber den echten Vorteil sehe ich da nicht). Diese einfach jedesmal unter den Aufruf der Funktion zu klatschen, wäre natürlich auch Quatsch, das vergisst man vielleicht irgendwann mal (und wäre nicht im Sinne einer Funktion, die ihre Aufgabe komplett und selbstständig erledigen soll). Das war bislang der einzige Fall, in dem ich ein goto eingesetzt habe (abgesehen vielleicht von ersten Gehversuchen mit AmigaBASIC ), aber hier finde ich es einfach ok. Und in solchen Fällen teile ich einfach nicht die Meinung, dass das ach so böse goto um jeden Preis vermieden werden soll, koste es was es wolle, und ansonsten soll man in der Hölle schmoren...

unskilled

namespace
{
  void func_helper()
  {
    for(...) { 
      for(...) { 
        for(...) { 
          if(...) { 
            for(...) { 
              if(...) { 
                //... 
              } else { 
                return; 
              } 
            } 
          } 
        } 
      } 
    } 
  }
}

int func() { //toller nebeneffekt: man sieht jz hier so gar durch...
  func_helper();
  //eine abschließende Anweisung 
}

Abgesehen davon kann man func_helper noch weiter aufsplitten...
vor allem das zeugs nach dem if(...) könnte auf jeden fall noch weiter ausgelagert werden - mehr als 3-4 Ebenen hab ich eigtl nie - und Fkt haben eigtl immer ne einstellige Zahl als Zeilen-Länge... Bis jetzt konnte ich mich (außer in der main-fkt) da immer dran halten...

bb

_matze

Damit hast du genau den Fall dargelegt, den ich vermeiden wollte. Nämlich eine unnötige, zweite Funktion (hatte ich ja gesagt). Ist eine Möglichkeit, klar. Meine aber auch (und einen qualitativen Unterschied kann ich da nicht entdecken).

EDIT: Und weiter aufsplitten ist doch auch unsinnig, wenn in den ganzen Schleifen nix weiter passiert, als das was in der innersten if-Anweisung steht. Das bringt nichts weiter, als das man beim Verstehen des Konstrukts noch zusätzlich zwischen mehreren Funktionen wechseln muss. Das Verteilen von Aufgaben auf mehrere Funktionen ist meist sehr sinnvoll, keine Frage. Aber ein solches Konstrukt sehe ich als eine Aufgabe an, das darf auch in einer Funktion stehen.

JustAnotherNoob

fkt_helper finde ich auch unschön.
Man sagt ja, dass verschachtelte Schleifen normalerweise die Komplexität haben eine Funktion zu bekommen, dann kriegen sie auch einen ordentlichen Namen.
Wenn man es wirklich nur fkt_helper nennen kann, weil die Aufgabe der Schleife nicht seperierbar ist, oder der in der Funktion noch folgende Code sowieso minimal ist würde ich in zweiter Linie auch ein goto als gerechtfertigt ansehen. Aber in erster Linie würde ich mal schauen, ob ich ganz ohne Sprünge oder Flags auskommen kann.

unskilled

natürlich sollte man den namen auch richtig wählen...

oder nennt ihr eure fkt auch immer foo und bar oder test?

bb

JustAnotherNoob

wollte eigtl. nur darauf hinaus, dass man es nicht wie eine reine Hilfsfunktion betrachten sollte, sondern es nur tun sollte, wenn der Code eine eigene Funktion rechtfertigt.

Bitsy

unskilled schrieb:

Hast du denn schon ne Idee für den Algorithmus, um die gotos und labels rauszubekommen? Mir würde nämlich nichts einfallen, was dann besseren Code erzeugen würde als bis jz mit den gotos... ^^
Würde mich nämlich mal interessieren

bb

Ca. 75% der Funktionen lassen sich wunderbar auflösen. Weitere 15% kriegt man durch Vervielfachung des letzten Blocks, sofern er letztlich ein return value; darstellt. Der Rest ist äußerst hartnäckig und - siehe meine Frage im letzten Post - wohl nicht unbedingt mit einfachen Patterns zu erschlagen.
Muß dazu sagen (das Ding ist alt!) es handelt sich hier um 68000er-Code der mit einem (Gottseidank) kaum bis gar nicht optimierenden Compiler erstellt wurde.

@hustbaer:
zu komplex - kann praktisch alles drüber stehen. Allerdings ist mir aufgefallen, daß die Funktionen, die dieses Muster aufweisen, alle zu einem ähnlichen Typ gehören. In 'gotolosem' C kann man solche 'Durchlauf'-Posten eigentlich nur über switch-case realisieren, bei denen breaks fehlen.
Bin noch nicht so weit, daß ich weiß, was da wo passiert. Vielleicht ist es ja sogar etwas in der Art. Wenn ich was finde, schreib ich's hier rein.

Jedenfalls bin ich froh, daß es ein goto gibt, sonst wären diese Zwischenstufen gar nicht möglich
Das Programm selbst läuft wunderbar - habe alle 68000er-Opcodes über Funktionen nachgebildet, AtariST-Gemdos/Xbios/Hardware ist nicht sehr schwer umzusetzen, nur die inverse Endianess hat mir anfangs zu schaffen gemacht. Jetzt will ich das Ganze bis auf schönes C++ hochbringen - rein hobbymäßig und ohne Zeitdruck.
Retro-programming - Dungeon Master ftw

xBlackKnightx

unskilled schrieb:

xBlackKnightx schrieb:

funktion hat doch den nachteil dass es ausserhalb der maincode ist. also alle variablen in maincode sind in der funktion nicht mehr gültig

Soll ich dir jetzt erklären, wie man ner Fkt Parameter übergibt? Oo
Bevor du jetzt von Rechenzeitverschwendung anfängst: Der Compiler wird es (wenn es sich denn lohnt) eh inlinen - so bald sich das nicht mehr lohnt, wirst du auch keinen Unterschied merken...

bb

und wenn es 10 parameter sind ? alle übergeben? viel zu viel codeüberfluss. da braucht goto weniger schreibarbeit.

Nexus

xBlackKnightx schrieb:

und wenn es 10 parameter sind ? alle übergeben? viel zu viel codeüberfluss. da braucht goto weniger schreibarbeit.

Wenn deine Funktion 10 Parameter hat, liegt mit grosser Wahrscheinlichkeit ein Designfehler vor. In den allermeisten Fällen kann man die Variablen dann zu Klassen zusammenfassen.

Bitsy

und hier noch'n destruktives Fehldesign

class trick
{
  public:
   ~trick() { cout << "aua!" << endl; }
};

void func(void)
{
  trick me;
  for (;;)
  {
    return;
    for (;;)
    {
    }
  }
}

unskilled schrieb:

...und Fkt haben eigtl immer ne einstellige Zahl als Zeilen-Länge...

Sehr sinning
Aber bin auch froh, wenn es viele so machen. Somit ist mein Code jedenfalls schon mal professioneller