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.