Früher war das durchaus eine gängige Praxis. Delphi selber verwendet das teilweise aus der folgenden Problematik: funktionen innerhalb eines Objektes können nicht als CallBack an die Windows-API übergeben werden, da jede Funktion innerhalb eines Objektes als zusätzlichen Parameter den Pointer auf das entsprechende Objekt mitbekommt. Deswegen legt die VCL speicher ein, in welchem eine "prozedur" hinterlegt wird die dann die entsprechende Funktion innerhalb des Objektes anspringt. Die Adresse des Speicherbereiches wird dann als CallBack an die API übergeben.

DAS IST ABER EINE AUSNAHME!!!! In der Regel macht man heutzutage keinen Selbsmodifizierenden Code mehr aus den folgenden Gründen:

- Selbstmodifizierender Code ist zu fehleranfällig (bis das mal läuft...)
- Mann kann diesen Bereich extrem schlecht debuggen
- Es ist im allgemeinen mittlerweile ein schlechter Programmierstiel
- Die übersicht im Source leidet deutlich darunter
- es bringt (im Gegensatz zu früher zu DOS und i386 Zeiten) keine Geschwindigkeitsvorteile mehr!

Deswegen Rate ich: vergiss es gleich wieder!

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Wenn du einen richtigen Compiler machen willst, dann kannst du dir ja mal das Minimum Beispiel von MASM ansehen. Da wird nur eine MessageBox angezeigt und die EXE Datei enthält nur weniger Befehle. Daher kann man daran gut den allgemeinen Aufbau erkennen. MASM kann kostenlos von http://www.masm32.com/ geladen werden. Dieser Debugger ist auch hilfreich http://home.t-online.de/home/Ollydbg/.

Ich hatte eigentlich damit vor Objekte in meinen openGL-Programmen zuladen. Ich nehme einfach den von Delphi fertig compilte Code für das Objekt, und speichere dies in einer Datei ab. Diese wird dann in den Arbeitsspreicher geladen und ausgeführt. Müsste doch eigentlich gut klappen... ...oder gilt auch dann SchodMCs Rat?
Mfg
IFlo

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut

So einfach geht das nicht weil dann die Referenzen auf andere Code Teile nicht stimmen. Das sind z.B. globale Funktionen, nicht virtuelle Methoden und viele Arten von Konstanten. Daher gibt es in einer Exe Datei den Bereich mit den Relokations, in dem steht wo welche Addressen angepaßt werden müssen. Auch wenn der nur bei DLL tatsächlich benötigt wird.
In einer früheren Version einer Engine habe ich mal einen Compiler eingebaut der eine Art minimales C++ zu Delphi kompatiblen Klassen kompiliert hat, so daß die kompilierten Klassen und die original Delphi Klassen austauschbar waren und es wegen den virtuelle Methoden auch beim Aufruf keinen Unterschied machte.
Das Testen von solchem Code geht eigentlich ganz gut mit dem CPU Fenster von Delphi. Wenn man richtig dokumentiert wie man eigenen Code einbindet, dann dürfte das eigentlich machbar sein.

Vielleicht ist es leichter, sog. Compiler - Construction - Tools zu verwenden. Ich hoffe, der folgende Link hilft ein bisschen.
http://www.thefreecountry.com/programming/compilerconstruction.shtml

Hab leider von diesem Thema selbst wenig Ahnung.

Mfg Alzheimer

Auch wenn TP 3.0 schon sehr alt ist, kann man davon lernen, denn der TP3.0 Compiler ist ein 1 Pass Compiler mit Top Down Parser (ähnlich wie der Parser im Script Tutorial) und die Code Generierung ist erschreckend einfach gehalten. Hier wird das zeimlich genau beschrieben:
http://www.pcengines.ch/tp3.htm

Natürlich ist diese Vorgehensweise heutzutage nicht mehr modern, aber wenn man bedenkt, daß man für solch einen Compiler nur aus wenigen Prozeduren besteht, dann ist das schon beieindruckend. Für eine Scriptsprache dürfte das Verhältnis zwischen Aufwand und Leistung in Ordnung sein.