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