StackReturn

[stahli]

Hallo zusammen,

mal eine grundsätzliche Frage:

Ich habe verschachtelte Objekte, die rekursiv durchgearbeitet werden. Unter bestimmten Umständen muss ich die Rekursion abbrechen (also sofort aus der aktuellen Methode raus) und einige Ebenen höher weiter machen. Quasi also im Aufrufstack an eine bestimmte Stelle zurück springen.

Aktuell ermittle ich einen höher liegenden "Interessenten", der von den tieferen Objekten (über eine Owner-Kette) seine Zuständigkeit erklärt.
Die tieferen Objekte haben somit ihre Arbeit einzustellen, biss der "Interessent" weiter machen kann.

Dieses "Interessentenobjekt" wird aktuell in einer globalen Variable verwaltet.
Ist dieses definiert und das aktuelle Objekt nicht diesen "Interessenten-Objekt", muss es seine Methode verlassen.

Das funktioniert, aber gibt es eine bessere/elegantere Lösung?
Ich hatte irgendwie zunächst an Callbacks o.ä. gedacht, aber so richtig komme ich da gedanklich nicht klar.
Aktuell sehe ich keine bessere Lösung als den Abgleich mit einer "Interessenten-Instanz" und Exit aus den Methoden.


(Dass man diese Interessenteninstanz als Parameter weiter geben könnte, weiß ich. Das soll nicht das Problem sein.)


Anbei mal ein kleines Testprojekt.
(Kaspersky hatte die Exe mal bemeckert bei mir.)

[Uwe Raabe]

Zitat:

Zitat von stahli (Beitrag 1483998)

Aktuell ermittle ich einen höher liegenden "Interessenten", der von den tieferen Objekten (über eine Owner-Kette) seine Zuständigkeit erklärt.

In dem Beispiel bestimmt die Instanz #7 dass die #3 der Interessent ist und nicht die #3 selbst. Ist das jetzt so gewollt, oder könnte die #3 auch unabhängig von der #7 dies tun? Das Beispiel ist halt sehr abstrakt.

[stahli]

Nein, Instanz #7 weiß nicht ob und wer sich meldet.
Anders gesagt, jede Instanz kann nach oben anfragen, ob sich irgendein Interessent findet (könnte auch zufallsbasiert sein).
Das Ganze läuft recht dynamisch ab.

Stimmt, das war etwas zu sehr vereinfacht.

Aber inzwischen bin ich auch überzeugt, dass es keine bessere Lösung gibt, als eine globale oder Parameter-Instanz zu verwenden.
Im Grunde bräuchte ich sonst so etwas wie einen Rücksprungpunkt im Stacktrace (ähnlich einem Haltepunkt), wobei dann aber alle zwischenliegenden Methoden sofort verlassen werden, bis der Rücksprungpunkt erreicht ist.
Das wird so nicht möglich sein und meine umgesetzte Lösung funktioniert ja auch sehr gut. Ich muss eben nur jeweils auf eine definierte Interessenteninstanz prüfen und ggf. mit Exit die Methode verlassen.

[himitsu]

Statt rekursiv könntest du auch iterativ arbeiten, dann ist ein Umschalten viel einfacher, da man direkt springen kann, ohne alle Zwischenstation durchlaufen zu müssen.

Es gibt sogar ein TStack<T>, was man nutzen könnte.
(oder TQueue<T>, jenachdem wie rum gefüllt/verarbeitet wird ... FIFO/LIFO)

[stahli]

@himitsu

Danke, aber das wird für mich nicht passen.
Ich parse Code und baue den um (das wird nochmal ein neuer, effektiverer Ansatz für meinen Optimizer).
Der Ablauf soll dann nicht von außen gesteuert werden sondern sich durch die Logik der einzelnen Klassen ergeben.

[himitsu]

Parsen lassen könntest'e Code aber auch durch LSP?

[stahli]

Ich will ihn komplett umbauen und formatieren. Da komme ich wohl nur auf meinem Weg richtig mit klar.

Für ein evtl. späteres Umbenennen bestehender Variablen/Methoden könnte es natürlich nützlich sein.
Muss ich dann mal schauen, ob ich damit dann zurecht komme...

[himitsu]

Es gibt zwei EXEn im BIN-Verzeichns.

Die Eine macht ObjectiveC zu Delphi (nutzt Emba zum Übersetzen von MacOS-Headern, um damit auf iOS/MacOS zuzugreifen)
und die Andere macht Delphi zu C.

Wenn ich das richtig verstanden hab dann kann man sich via LSP einen Code von Delphi oder C in einen Objektbaum übersetzen lassen.
Praktisch so ähnlich, wie gewisse XML-Klassen es mit einer XML-Datei machen.
Den Baum kannst dann durchgehn, ignorierst einfach alles, was dich nicht interessiert, und schon hast auch keine Probleme, wenn die Delphi-Language mal wieder neue Features bekommt.

[stahli]

Wenn ich aber XML parsen muss, habe ich nicht viel gewonnen.

Im Prinzip habe ich Schlüsselwörter definiert und zu jedem Schlüsselwort ein Parse-Objekt.
Das prüft dann alles ab, in welchem Kontext es steht, ob es sich für irgend etwas überhaupt zuständig fühlt, wie es seinen Inhalt formatieren muss usw.

Zunächst wird eine Stringlist in einzelne Wörter zerlegt und diese werden in einer Liste gesammelt.
Dann starte ich das Parsing von einem TUnitFile-Objekt aus, dem die Liste mit Startpunkt 0 übergeben wird.
Der Rest geht dann automatisch. Ich muss halt die Regeln nur in den Parsing-Klassen verpacken.

Worte, die keinem Schlüsselwort entsprechen oder im Kontext nicht passen, bleiben einfacher Text.
Ob der Code insgesamt konkret gültig ist, muss ich ja nicht prüfen. Mich interessieren nur einige Teile und z.B. ob Begin-End-Blöcke korrekt aufgehen.

Das heißt, neue Sprachfeatures sollten i.d.R. unschädlich bzw. in einfacher Weise noch nachträglich zu berücksichtigen sein.
Ich war ja schon sehr weit, will aber jetzt nochmal ein paar Dinge optimieren.

Im Bild sieht man unter dem Mauszeiger eine erkannte Interface-Deklaration.(Man sieht, dass das "end;" dann auch wieder als eigenständige Anweisung erkannt wurde.)
Aus dem "prop" wird jetzt als nächstes ein komplettes Property mit Getter und Setter erzeugt.
Macht richtig Spaß jetzt. :-)

[stahli]

Zitat:

Zitat von himitsu (Beitrag 1484042)

Statt rekursiv könntest du auch iterativ arbeiten, dann ist ein Umschalten viel einfacher, da man direkt springen kann, ohne alle Zwischenstation durchlaufen zu müssen.

Es gibt sogar ein TStack<T>, was man nutzen könnte.
(oder TQueue<T>, jenachdem wie rum gefüllt/verarbeitet wird ... FIFO/LIFO)

Jetzt muss ich mir das doch nochmal anschauen, aber aus einem etwas anderen Grund.

Ich will ja auch auskommentierten Text als Code interpretieren und die entsprechend auch kontextbezogen.
Das heißt, ich muss so etwas wie Branches organisieren.
Wenn ich in einen auskommentierten Block laufe, kann der irgendwann unabgeschlossen enden oder sogar ein "end." enthalten, was die Unit beenden würde.
Der hinter dem Block stehende echte Code, sieht aber ganz anders aus.

Insofern habe ich zwei völlig unterschiedliche Wege, die sich an einem bestimmten Punkt verzweigen, sich aber auf den gleichen vorherigen Kontext beziehen.

Also werde ich die verschachtelte Struktur beibehalten, aber dann mit "Iteratoren" arbeiten, die sich durch die Struktur bewegen können, und den jeweiligen Kontext beinhalten.
Das Rückspringen wird dadurch (wie Du geschrieben hast) tatsächlich einfacher und ich kann für auskommentierte Blöcke einfach eine Iteratorkopie erzeugen und sich diese bis zum Ende des auskommentierten Blockes durchwühlen lassen.
Insgesamt wird das aber schon auswendiger als der bisherige rekursive Ansatz. Nur mit dem kann ich "Abzweigungen an beliebigen Stellen" wieder schlechter umsetzen.

Ich hatte die Aufgabe zwar schon mal weitestgehend in einer verwalteten Liste umgesetzt (ohne Verschachtelungen), das war aber sehr aufwendig und hat eine Vielzahl an Sonderfällen ergeben, die zu berücksichtigen waren, so dass ich den neuen Ansatz nochmal versuchen wollte.

Mal sehen, um das jetzt mit einem Iterator besser funktioniert...

(Wie gesagt, ohne die "Kommentarbereich-Branches" könnte ich jetzt schon gut der Rekursion arbeiten.)