StackReturn

[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 von 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)

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.)