Zitat von
Alfi001:
Das mit dem "ins Gehege kommen" war wohl etwas unglücklich formuliert. Es ist aber so, dass die Typeninformationen der beiden TStringlist-Versionen in unterschiedlichen Datensegmenten liegen. Und das kann bei manchen Operationen zu extremen Problemen führen.
Im Falle der Stringliste kann ich sie dir benennen. Es ist genau eine: TStringlist.assign(Bla:tpersistent)
Zitat von
Alfi001:
Ähm, wir sprachen hier aber nicht von einer geänderten System
Unit (wer macht denn so was???) sondern von normalem ungepatchten Delphi.
Schon klar, mir viel nur ein das ich mal versucht hab das Problem komplett aus der Welt zu schaffen, und das hat sogar Funktioniert nur ist es ne dumme Sache solche Patches immer wieder durchzuführen wenn ne neu Delphi Version rauskommt.
Und für die meisten Sachen gibts ja Interfaces...die sind sowieso viel schöner und sauberer.
Zitat von
Alfi001:
Diese Behauotung verstehe ich nun absolut nicht. Wie willst du denn in der
DLL andere Compilerschalter nur für die auszutauschenden Objekte verwenden? Die Einstellungen müssen, genau wie bei dem
Package global übereinstimmen.
Also, zusammenfassend: mit DLLs funtioniert es nur dann wenn beide beteiligten, also die Applikation und die
DLL, die selbe
VCL verwenden. Das heisst, dass sie mit Runtime-Packages erzeugt werden müssen (sonst liegen im Speicher später 2 komplette Kopien der
VCL rum!). Daraus folgt aber, dass die hier selben Einschränkungen gelten wie für Packages. Warum also nicht direkt Packages verwenden???
Dies gilt nur für die
VCL. Wenn ich z.b. auf beiden Seiten Bibliotheken mit unterschiedlichen kompiler schaltern verwende, dies aber nicht übergreifend, dann macht das durchaus Sinn. Und das wirst du mit einer
BPL nie hin kriegen.
Zu deiner Frage also eigentlich sollte er ein
Package verwenden...ausser es liegt ein Szenario vor in dem einige ausgewählte Units mit unterschiedlichen Kompilerschaltern genutzt werden müssen....
Ein
Package ist auf jeden Fall sauberer wenn man sein Projekt von Grund auf so plant. Wenn er ne größere Sache umstellt kann es durchaus sein das eine
DLL und ein paar schmutzige Tricks vorzuziehen sind.
@Elvis:
Quick and Dirty is an Art , isn't it?
Ausserdem ist es kosteneffektiv und Arbeistplatz sichernd, wenn nur du weist warum das TROTZDEM geht. Zugegeben es ist nicht schön....
Ausserdem ist der von Delphi mitgelieferte IS Operator so ziemlich das langsamste was es in dieser Richtung geben kann,
Wenn man mal das Verfahren der Infopower leute nimmt geht einiges wesentlich schneller!!! Performance ist ja leider seit Dotnet nicht mehr in Mode.