Naja Markierung ginge nicht so gut. Sind schließlich Pointer. Höchstens indem man in nem Set die Indizes merkt oder so.. Außerdem werden am Ende der Schleife das Aktuelle mit allen vorherigen Elementen verglichen, es würde also den Algo ändern.
Ich meinte auch eher ausserhalb. Aber ich kenn dein Problem nicht genau genug, um spezifisch zu antworten. Jedoch wäre mir bereits die Verringerung der Zeitkomplexität Anreiz genug, wenigstens darüber nachzudenken. Auch das "mit allen vorherigen vergleichen" macht mich etwas stutzig, meinst du nicht, hier gibt es eine effizientere Lösung? Sorry, falls ich mich total irre, kann gut sein, dass alles okay ist. Ich bin halt noch schnell skeptisch, wenn ein Algorithmus viele solche Operationen beinhält.
Ich mache das doch genauso. Wann immer es Sinn macht, etwas auszulagern, tue ich das auch. Im Beispiel oben macht es aber meiner Meinung nach keinen Sinn. Ich wüsste nichtmal, wie ich die Funktion nennen sollte.
Wie würdest du die For-Schleifen beschreiben, was tun die? Einen sinnvollen Namen zu finden sollte eigentlich möglich sein. Das Problem hättest du ja auch, wenn du Kommentare statt eigene Funktionen einsetzen würdest.
Wie gesagt: goto kann okay sein. Aber wenn eine Funktion so gross ist und darin Sprünge vorkommen, finde ich es recht schwierig, gleich alles zu überblicken. Es kann auch leicht passieren, dass mal etwas übersehen wird (eben auch die erwähnten Seiteneffekte). Und Debugging wird wirklich viel einfacher, wenn man plötzlich nur noch halb so viele Stackvariablen und Parameter hat, von denen einige sogar durch const eingeschränkt sind. Auch die Anzahl Ablaufpfade verringert sich und das Prüfen von Pre- und Postconditions über assert ist viel weniger komplex, weil hier jede Funktion selbst zuständig ist und sich der Ausführer eines Algorithmus keine Gedanken mehr um solche Dinge machen muss.
Und ich gehöre auch nicht zu der Sorte Menschen, die Funktionen mit mehr als einer gewissen Anzahl Zeilen grundsätzlich immer böse finden. Meistens tendieren diese Funktionen aber dazu, eher komplizierte Dinge zu tun (wie z.B. verschachtelte Schleifen mit if-Bedingungen). Kompliziert im Sinne von: Man braucht viel Zeit, um Code zu verstehen, weil für den Algorithmus irrelevante Details nicht ausgelagert wurden - und die Gefahr der oben erwähnten Probleme ist grösser. Aus diesem Grund versuche ich, so weit sinnvoll aufzuteilen. Man findet dann auch die Funktionalität leichter wieder, wenn man vernünftige Funktionsnamen hat. Klar, dass "sinnvoll" wieder subjektiv ist, in diesem Punkt haben wir wohl eine etwas andere Ansicht.
Also zusammengefasst: Es gibt (wie für fast alles) berechtigte Anwendungsgebiete von goto. Die Alternativen scheinen mir in vielen Fällen aber nicht schlimm, besitzen jedoch ein paar hübsche Nebeneffekte. Das ist der Grund, wieso ich kaum goto verwende - nicht weil ich dem Dogma folgen will, so einer bin ich nicht. :p