Übergabe einer Klasse von EXE an DLL

[Zacherl]

Zitat von norwegen60:

Auch wenn die Aussage im Raum steht, dass uns das um die Ohren fliegt...
Wo ist das Problem? Ein anderer Programmierer hat dazu gemein, dass eine Klasse innerhalb Delphi auch nur ein Pointer ist und wenn beide Seiten über den Aufbau genau das gleiche wissen, würden beide auch gleich mit den Daten umgehen.

Solange du DLL und EXE mit exakt der gleichen Delphi Version kompilierst, "sollte" es funktionieren. Ob da nicht am Ende doch bei RTTI lastigen Anwendungen irgendwas um die Ohren fliegt, kann ich allerdings nicht genau sagen.

Edit: Wobei .. wenn ich grade nochmal so drüber nachdenke, dann könnte es diverse statische Speicherbereiche bzw. Singletons geben, die dann zwischen DLL und EXE nicht geshared werden würden. Das kann auch Probleme machen.

[mkinzler]

Deshalb besser Interfaces benutzen.

[norwegen60]

Mmh, wie schon weiter oben gesagt, habe ich mich mit Interfaces noch nicht beschäftigt.
Ich habs mir heute mal angeschaut, verstehe aber nicht ganz wieso es mir im Fall Delphi zu Delphi helfen soll.

Wie würden mein Projekt sich denn Ändern, wenn es per Interfaces laufen würde?

[Zacherl]

Zitat von norwegen60:

Wie würden mein Projekt sich denn Ändern, wenn es per Interfaces laufen würde?

Im Grunde nicht viel. Du müsstest dir für jedes Object alle Methoden, die über die Programmgrenzen hinweg aufgerufen werden in einem Interface deklarieren. Danach leitest du dein bestehendes Objekt nicht mehr von TObject , sondern von TInterfacedObject und IMyInterface ab.

[norwegen60]

Zitat von Zacherl:

Im Grunde nicht viel. Du müsstest dir für jedes Object alle Methoden, die über die Programmgrenzen hinweg aufgerufen werden in einem Interface deklarieren. Danach leitest du dein bestehendes Objekt nicht mehr von TObject , sondern von TInterfacedObject und IMyInterface ab.

Hier liegt eines meiner Verständnisprobleme. Eigentlich will ich ja gar keine Methoden über die Programmgrenzen hinweg aufrufen sondern nur Felder. Ausser wenn bei den Properties auch die Getter und Setter gemeint sind. Wäre auch ein property Power: Realread FPowerwrite FPower; betroffen?
Oder ein

Delphi-Quellcode:

  TMessValue = class(TObject)
    Load: Real;
    Power: Real;
  end;

[Zacherl]

Interfaces können leider ausschließlich Methoden besitzen. Zugriff auf Felder müsstest du dann alle über Getter/Setter kapseln. Ich würde allerdings mal behaupten, dass wenn du in deiner Klasse ausschließlich triviale Datentypen hast (String und Arrays sind davon ausgenommen) und die Klasse zudem keine Seiteneffekte in der VCL/RTL auslöst, solltest du relativ sicher sein. Höchstens irgendwelche RTTI Geschichten könnten dann noch Probleme bereiten.

[jaenicke]

Es gibt viele Stolpersteine, wenn man Klassen so über DLL-Grenzen hinaus benutzt. Das fängt schon bei einem simplen is bzw. as an, das nicht funktioniert. Das wird aber teilweise auch in den Quelltexten der RTL und VCL benutzt. Deshalb erlebt man da durchaus die eine oder andere Überraschung...

Die Umstellung auf Interfaces lohnt sich. Damit ist man zukunftssicher unterwegs und muss nicht mit Workarounds anfangen, wenn es Probleme gibt. Zumal die Fehlersuche im Zweifelsfall enorm Zeit kostet.

Dazu kommt, dass man die Schnittstelle zur DLL auch bei Erweiterungen nicht ändern muss, sondern auf verschiedene Versionen eines Interfaces prüfen kann, so also zwischen verschiedenen Versionen der DLL und des Hostprogramms kompatibel ist. Wenn man das denn möchte.

Vor allen braucht man sich aber nicht darum zu kümmern, dass der Speicher der übergebenen Objekte nicht zu früh oder zu spät freigegeben wird usw., da das automatisch passiert, wenn die Referenzen z.B. auf nil gesetzt werden. Gerade bei mehreren beteiligten Modulen ist das sehr hilfreich.

Für die generischen Listen usw. haben wir z.B. Container mit Interface-Anbindung erstellt.