Interfaces und die DLL/Anwendung Grenze.

[QuickAndDirty]

Hallo,
es gibt bereits einen ähnlichen Thread von heute, aber ich habe eher allgemeine Fragen.

Es gibt ja das Problem das Objekte in Anwendungen und DLL unterschiedliche RTTI Vectoren haben,
weshalb der IS Parameter nicht Funktioniert und es einige Risiken gibt wenn unterschiedliche
Compilerschalter benutzt wurden wenn man ein Objekt über die DLL/Anwendungs Grenze hinweg verwendet.

Nun habe ich des Öfteren vernommen, das es durchaus möglich ist Objekte in einer DLL zu erzeugen und sie
als INTERFACE in die Anwendung weiter zu geben. Ebenso auch umgekehrt.

1. Was muss ich dabei beachten?
2. Funktioniert die Referenzzählung über die DLL/Anwednungsgrenze hinaus?(müsste sie ja eigentlich)
3. Was ist mit Interfaces die String Parameter haben? Sharemem oder nicht?

[sirius]

1. Nix, du musst nur die gleiche IID (GUID) verwenden. Das ist ja auch das einzige, worauf sich ein Interface bezieht, da es ja keine RTTI besitzt.
2. ja klar
3. Nach wie vor genauso ungünstig. Da ändert sich leider nichts.

[mkinzler]

Zitat:

3. Was ist mit Interfaces die String Parameter haben? Sharemem oder nicht?

WideString verwenden

[QuickAndDirty]

@MKinzler:
Warum WideString?
Ist das nicht auch nur ein PWidechar? Gibts dazu bessere Compiler Magic?

[himitsu]

aus http://www.delphipraxis.net/internal...044677#1044677

Zitat:

Zitat von himitsu

Ansonsten könntest du auch einfach einen WideString nehmen, dieser wird von Delphi intern auf einen OLEStr umgeleitet, womit er über den Speichermanager der ole32.dll läuft
und demnach auch über Modulgrenzen hinweg verwendet werden kann.

[QuickAndDirty]

Muss ich die WideStrings dann zur weiteren Verabreitung noch mal zu DelphiSTRING Strings konvertieren, oder macht der
compiler das von alleine? Reicht ein Type Cast(vermutlich nicht)?

Gibt es die Stringfunktionen auch alle für widestring? wenn ja , warum sollte man dann überhaupt noch Delphistrings benutzen?
Sind die WideStrings imperformanter?

Sorry, aber irgendwie brauch ich mehr input.

[mkinzler]

man kann String und WideString gegenseitig zuweisen. mehr aber nicht. WideString ist kein nativer Stringtyp. es wird keine Referenzzählung unterstützt.

[QuickAndDirty]

Zitat:

Zitat von mkinzler

man kann String und WideString gegenseitig zuweisen. mehr aber nicht. WideString ist kein nativer Stringtyp. es wird keine Referenzzählung unterstützt.

Das bedeutet ich muss immer mit Kopien von Widestring arbeiten kann den aber problemlos über model grenzen hinweg weitergeben...
...dann muss ich mich aber auch um Instanzierung und Freigabe selbst kümmern?

[mkinzler]

Es kommt darauf an, was du alles mit dem String anfangen willst. String ist zwar performanter, aber durch ständiges umkopieren, geht dieser Vorteil schnell flöten.

Zitat:

...dann muss ich mich aber auch um Instanzierung und Freigabe selbst kümmern?

Nein, denn keiner der Typen ist eine Klasse.

[QuickAndDirty]

Ich sehe gerade man kann Widestrings nur mit eigenen Funktionen vergleichen etc. ? Wie in C .

Muss ich Widestring speicher eigenständig anfordern? Und wenn keine Referenzzählung unterstützt wird wie gebe ich Widestrings wider frei?

Gehen Widestrings nur über Getmem und Freemem?

[Apollonius]

Quatsch. Widestrings werden genauso durch Compiler-Magic verwaltet wie normale Strings. Es gibt allerdings tatsächlich keine Referenzzählung, was bedeutet, dass bei einer einfachen Zuweisung bereits eine Kopie gemacht wird. Wenn dir aber Performance nicht so wichtig ist, musst du dich um nichts kümmern.

[QuickAndDirty]

OK, und die Kopien werden dann Freigegeben wenn die Variable vom Stack verschwindet oder z.B. Ein Array of Widestring
verkleinert wird?

[Apollonius]

Exakt. Genau wie normale Strings, dynamische Arrays, Variants und Interfaces werden WideStrings automatisch finalisiert.

[sirius]

Zitat:

Zitat von QuickAndDirty

Und wenn keine Referenzzählung unterstützt wird wie gebe ich Widestrings wider frei?

Wie wahrscheinlich schon geklärt ist: Die Referenzzählung ist kein Muss um die Freigabe zu klären. Sie braucht man nur, wenn man mehr als eine Referenz haben möchte und eine automatische Freigabe realisieren will.

[QuickAndDirty]

OK, was passiert wenn ich widestrings on eine Procedur übergebe

Delphi-Quellcode:

Procedure(s:Widestring);
Begin

end;

copy on write ? oder Kopiert er den Widestring auch wenn ich ihn nur lesen will?

also würde DAS

Delphi-Quellcode:

Procedure(var s:Widestring);
Begin

end;
//oder
Procedure(in s:Widestring);
Begin

end;

notwendig werden?

[sirius]

Für die Performance wäre var bzw. const besser. Ansonsten wird kopiert.

(Seit wann gibt es "in"?)

Edit:
Mach dir aber deswegen keinen all zu großen Kopf in anderen Programmiersprachen wird immer und ständig kopiert (z.B. Java). Es ist nur ein kleiner Vorteil von Delphi den du damit über Bord wirfst. Fang deswegen ja nicht, ständig zwischen String und Widestring zu wechseln. Diese Zuweisungen dauern noch viel länger.


Edit2: Aber nochmal zu deiner eigentlichen Frage. Warum kann man Objekte nicht über DLL-Grenzen hinaus liefern? Das geht ja anscheinend nur so lange, wie du bereits mitgelieferte Klassen aus Delphi verwendest. Das Problem springt dir ja sofort ins Auge, wenn du eine eigene Klasse verwendest.
Bsp:
Erstelle in einer EXE eine Klasse:

Delphi-Quellcode:

type TmyClass=class
       procedure Foo;
     end;

Diese Klasse kannst du jetzt noch fertig implementieren.
Nachher willst du diese Klasse an die DLL übergeben. Und hier siehst du, jetzt kennt die DLL die Klasse nicht. Es reicht auch nicht aus, den Header nur zu schreiben. Du müsstest für die Klasse in der DLL auch eine eigene Implementation schreiben. Damit erkennst du, dass die Klassen nur den gleichen Namen haben, aber niemals den gleichen Inhalt (auch, wenn du sie gleich implementierst). Außerdem ist es ja witzlos eine Klasse zweimal zu implementieren. Aber genau das würdest du machen, wenn du bspw eine StringList an die DLL übergibst. Du hättest die StringList zweimal in deinem Process.

Wenn du jetzt ein Interface verwendest:

Delphi-Quellcode:

type ImyClass=interface
       ['{8105D05C-D7F1-41A3-B98C-860E5B89FBD8}']
       procedure Foo;
     end;
 
     TmyClass=class(TInterfacedobject,ImyClass)
       procedure Foo;
     end;

...dann reicht es eben aus, nur den Header in die DLL zu kopieren. Das Interface hat ja auch keine Implementation.

Wenn du dir das bewusst machst, siehst du dass (unabhängig von Referenzzählung und allen anderen Vorteilen von Interfaces) nur Interfaces verwendet werden können.

[QuickAndDirty]

Zitat:

Zitat von sirius

Für die Performance wäre var bzw. const besser. Ansonsten wird kopiert.

(Seit wann gibt es "in"?)

Keine Ahnung wie ich darauf kam....irgendwo (Vermutlich nicht in delphi, habe ich so etwas mal gesehen) Const ist wohl gemeint gewesen.

Zitat:

Zitat von sirius

Edit:
Mach dir aber deswegen keinen all zu großen Kopf in anderen Programmiersprachen wird immer und ständig kopiert (z.B. Java). Es ist nur ein kleiner Vorteil von Delphi den du damit über Bord wirfst. Fang deswegen ja nicht, ständig zwischen String und Widestring zu wechseln. Diese Zuweisungen dauern noch viel länger.

OK, also verliere ich einen Geschwindigkeitsvorteil....bei Java wird zwar auch ständig Kopiert und für jede zusammensetzung in der ein String mal existiert hat ein Objekt verwaltet, aber dafür werden die auch alle in Großen Blöcken von der GC auf einen Schlag freigegeben....na ja. Mal sehen wie die Performance lagged. Computer machen kopier vorgänge im Speicher ja mittlerweile sehr schnell.

Zitat:

Zitat von sirius

Edit2: Aber nochmal zu deiner eigentlichen Frage. Warum kann man Objekte nicht über DLL-Grenzen hinaus liefern? Das geht ja anscheinend nur so lange, wie du bereits mitgelieferte Klassen aus Delphi verwendest. Das Problem springt dir ja sofort ins Auge, wenn du eine eigene Klasse verwendest.
Bsp:
Erstelle in einer EXE eine Klasse:

Delphi-Quellcode:

type TmyClass=class
       procedure Foo;
     end;

Diese Klasse kannst du jetzt noch fertig implementieren.
Nachher willst du diese Klasse an die DLL übergeben. Und hier siehst du, jetzt kennt die DLL die Klasse nicht. Es reicht auch nicht aus, den Header nur zu schreiben. Du müsstest für die Klasse in der DLL auch eine eigene Implementation schreiben. Damit erkennst du, dass die Klassen nur den gleichen Namen haben, aber niemals den gleichen Inhalt (auch, wenn du sie gleich implementierst). Außerdem ist es ja witzlos eine Klasse zweimal zu implementieren. Aber genau das würdest du machen, wenn du bspw eine StringList an die DLL übergibst. Du hättest die StringList zweimal in deinem Process.

Wenn du jetzt ein Interface verwendest:

Delphi-Quellcode:

type ImyClass=interface
       ['{8105D05C-D7F1-41A3-B98C-860E5B89FBD8}']
       procedure Foo;
     end;
 
     TmyClass=class(TInterfacedobject,ImyClass)
       procedure Foo;
     end;

...dann reicht es eben aus, nur den Header in die DLL zu kopieren. Das Interface hat ja auch keine Implementation.

Wenn du dir das bewusst machst, siehst du dass (unabhängig von Referenzzählung und allen anderen Vorteilen von Interfaces) nur Interfaces verwendet werden können.

Ich weiß wie man Klassen über Modulgrenzen hinweg verwenden kann. Ich mache das und das geht. Man darf eben keinen IS operator verwenden und muss einfach nur die UNITS mit den KLASSEN in Anwendung und DLL einbinden. Das Funktioniert dann sobald man Strings
benutzt nur noch mit Sharemem und sobald man das in größerem Umfang macht findet man Fehler nicht mehr, weil sich z.B. Packages die DLLs einbinden welche Objekte erzeugen die in der Anwendung direkt genutzt werden dann auf einmal zwar Kompilieren lassen und auch verwenden lassen nur leider nicht als Designtime Package installieren lassen...aus heiterem himmel...etc.
(Bei mir war der Grund wohl eine neue ElevateDB Version da hat da gab es Unterschiede in DLL und Anwendung die aus dcu leichen herrührten...etc.)
Außerdem nutze ich zur Laufzeit eingebundene DLLs und zur Laufzeit eingebundene Packages ....aus heraus und hinein Packages kann man Klassen ja super verwenden.
Es geht mir nicht darum anderen Entwicklern eine fertige DLL zur Verfügung zu stellen sondern die Logik die hinter einer "Fassade"
steht per DLL(oder Package) beim Kunden austauschen zu können.

Werde vermutlich einges auf Interfaces mit WideStrings umstellen, weil ich mir so den Ärger mit den Persistenten Objekten erspare.