Interfaces und die DLL/Anwendung Grenze.

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