Objekt-Austausch zwischen EXE und DLL > wann möglich?

[Pfoto]

Hallo zusammen!

ich arbeite von Zeit zu Zeit an einer kleinen Anwendung,
die bisher auf BPLs aufgebaut ist.

Da ich jedoch gerne auch DLLs einsetzen möchte, ist meine
Frage, unter welchen Umständen ich Objekte austauschen kann.

Ich habe gelesen, dass es eigentlich problematisch ist,
da die EXE und DLL verschiedene Speicherbereiche benutzt.

In Sakuras eindruckvollem DLL-Tutorial sehe ich aber, dass
die Zeiger der Objekte scheinbar ohne Probleme weitergereicht
werden (z.B. wird das Hauptmenü über das PlugIn geändert).
Liegt das nun an der Unit ShareMem oder wie ist das zu begründen?


Für etwas Erhellung wäre ich Euch dankbar.


Gruß
Pfoto

[Elvis]

Du kannast links auf mein Profil klicken und dort auf "alle Beiträge von ...".
In der darauf folgenden Seite siehst du rechts oben eine filter box wo du "dll interfaces" rein tippst.
Nun solltest du alle meine Beiträge zu dem Thema sehen können, ich habe es hier oft genug gepredigt, man sollte also genug zum Lesen finden können. :-)

btw: Interfaces sind eine Möglichkeit um OO-Semantiken jenseits von Modul- Compilergrenzen benutzen zu können.

[Pfoto]

Moin Elvis,

ich habe mich wirklich vorher der Suche bedient und Dein Name kam
auch oft in den Beiträgen vor ;-)

Ein Zitat von dir:

Zitat:

"Delphi Interfaces erfüllen die COM-Pflichten, sie sind also binär kompatibel zueinander.
Auch wenn du sie in 2 Binaries kompilierst (Deine Echse und die DLL). "

Das was ich nicht verstehe:
In dem PlugIn-Modell von Sakura gibt es ja keine echten Interfaces, sondern nur
abstrakte Klassen als Schnittstelle.

Oder ist hier nur die Hauptsache, dass die Objekte in der gemeinsam Verwendeten
Schnittstellen-Unit definiert wurden?
Daher auch meine Frage, ob ShareMem zudem dafür sorgt, dass die Übergabe
der Objekte reibungslos funktioniert -- zumindest zwischen EXE und DLL, die mit
der selben Delphi-Verison kompiliert wurden.


Ich würde es halt gerne verstehen, auch wenn ich sozusagen auf die sicheren
echten Interfaces setzten könnte. Wobei es mir nicht unbedingt auf Kompatibilität
zu anderen Versionen oder Programmiersprachen ankommt.

Denn der Nachteil bei meiner jetztigen BPL-Lösung ist, dass es
allein wegen der Fremdbibliotheken extrem viele Dateien geworden sind,
die ich alle mitliefern müsste. Dabei soll mein Programm nur ein kleines
Tool sein, dass längst nicht alle Funktionalitäten der Bibliotheken benötigt.
Also praktisch mit Kanonen auf Spatzen geschossen...


Gruß
Pfoto

[mkinzler]

Interfaces sind ja eine besondere Form von abstrakten Klassen.
Ich hab das früher auch mit abstrakten Klassen und Dlls gelöst, geht natürlich auch.

[Bernhard Geyer]

Zitat:

Zitat von Pfoto

Denn der Nachteil bei meiner jetztigen BPL-Lösung ist, dass es
allein wegen der Fremdbibliotheken extrem viele Dateien geworden sind,
die ich alle mitliefern müsste.

Du kannst doch angeben was als BPL eingebunden wird und was in die Exe kompiliert wird.

[Pfoto]

Zitat:

Zitat von Bernhard Geyer

Du kannst doch angeben was als BPL eingebunden wird und was
in die Exe kompiliert wird.

Ja, aber aus nahezu jeder Bibliothek werden Funktionen auch von den PlugIns benötigt,
so dass ich so gut wie nichts in die EXE einkompilieren kann.

Aber wie ich eben beim ausprobieren festgestellt habe, haben die DLLs nun den
Nachteil, dass sie sehr groß werden können und es ebenso ineffizient ist,
Code mehrfach in verschiedenen DLLs zu besitzen.

Die perfekte Lösung wird es wohl nicht geben, da bleibe ich wohl
der Einfachheit halber bei meinem BPLs...
Vielleicht kann ich ja gezielt nur die benötigten Units zu einer großen
BPL zusammenfassen, mal sehen.


Gruß
Pfoto

[Elvis]

Zitat:

Zitat von mkinzler

Interfaces sind ja eine besondere Form von abstrakten Klassen.
Ich hab das früher auch mit abstrakten Klassen und Dlls gelöst, geht natürlich auch.

Aber nur mit dem gleichen Compiler kompiliert, richtig?
Interfaces erlauben, im Gegensatz zu abstrakten Klassen, aber auch is/as (da nicht an den Typ sondern an die GUID gebunden), und Versionierung.
Ich kann ja mal die Tage etwas zu dem StringList-DLL-Thread von letztlich basteln[1] und in die Codelib stellen.
Falls jmd. Interesse hat und ich es bis Montag verpeilt habe: einfach so lange per PN nerven, bis ich es gemacht habe. :mrgreen:

[1] Hatte ja schon etwas Sauce vorbereitet