DLL Integration kürzen

[Elvis]

Zitat:

Zitat von Apollonius

Zitat:

Interfaces haben eine standardisierte Art um Methoden aufzurufen

??? Interfaces verwenden standardmäßig doch auch nur eine VMT (Variants mit Interfaces drin sind eine andere Geschichte).

Du hast eine VMT pro Interface pro Instanz. Aber das ist nicht der Punkt.
Der Punkt ist, dass ein Interface, das auf die gleiche Art deklariert wird, immer auch die gleichen Methoden an den gleichen Slots haben wird.
Das ist eine Vorraussetzung von COM, und wir können es hier als eine Art compiler- & modul-übergreifendes Esperanto für Objekte benutzen. :-)

[Apollonius]

Zitat:

Der Punkt ist, dass ein Interface, das auf die gleiche Art deklariert wird, immer auch die gleichen Methoden an den gleichen Slots haben wird.

Der Punkt ist, dass eine Klasse, die auf die gleiche Art deklariert wird, immer auch die gleichen Methoden an den gleichen Slots haben wird, sofern, was auch für Interfaces gilt, auch die Vorfahren gleich deklariert wurden.

[Elvis]

Zitat:

Zitat von Apollonius

Zitat:

Der Punkt ist, dass ein Interface, das auf die gleiche Art deklariert wird, immer auch die gleichen Methoden an den gleichen Slots haben wird.

Der Punkt ist, dass eine Klasse, die auf die gleiche Art deklariert wird, immer auch die gleichen Methoden an den gleichen Slots haben wird, sofern, was auch für Interfaces gilt, auch die Vorfahren gleich deklariert wurden.

Nein, das ist nirgends standardisiert und kann sich mit jeder Compilerversion ändern. (Hat es IMO auch)
Außerdem reicht ein weiteres Feld vor dem letzten um alles über den Haufen zu werfen.
Klassen = Intramodulobjekte, mit der Ausnahme von Packages oder gemeinsam verwendeten Runtimepackages.
Interfaces = Intermodul- & Intercompilerobjekte

Klassen für letzteres zu benutzen ist wie Polymorphie mit Vanilla-C, möglich aber krank. Nicht zu vergessen es ist eine echte Bitch sowas zu dokumentieren.
Unsere Zunft produziert auch dann noch so schlechte Qualität, dass es beschämend ist, wenn man sich an alle Regeln und Good-Practices hält. Warum es unnötig noch weiter herausfordern, hmm? ;-)

[Apollonius]

Zitat:

Außerdem reicht ein weiteres Feld vor dem letzten um alles über den Haufen zu werfen.

Was haben denn Felder mit der VMT zu tun?
Und ich dachte immer, dass der Compiler einfach die erste virtuelle Methode an VMT-Slot 1 setzt, die zweite an Slot 2, usw. - bei Klassen wie bei Interfaces. Wie war das denn vor jenen Änderungen?

[Elvis]

Zitat:

Zitat von Apollonius

Zitat:

Außerdem reicht ein weiteres Feld vor dem letzten um alles über den Haufen zu werfen.

Was haben denn Felder mit der VMT zu tun?

Nichts, aber es ging nicht nur um ein Problem. Es geht darum, dass Klassen keine Versionierung erlauben und dass Klassen nicht unabhängig vom Compiler sind.
Du hast dich ein wenig zu sehr auf das eine Beispiel eingeschossen, was ich oben erwähnt habe. ;-)

btw: Meine DLL in dem Bleistift oben ist 17KB groß. Wie große wäre sie gewesen, wenn ich dort tatsächlich ein TStrings benutzt hätte? 300 KB, 400? ;-)

[Ralf Kaiser]

Zitat:

Zitat von Elvis

Quick&Dirty will wohl seinem Namen alle Ehre machen, hmm? :zwinker:
.

Sieht ganz so aus... :)

Zitat:

Zitat von Elvis

@Alf, Probleme kommen ganz einfach.
Du hast eine exportierte Funktion, die eine Referenz vom Typ TStrings nimmt und übergibst ihr natürlich eine Ableitung.
Hier kann es ganz schnell fies werden, da die übergebene Referenz ihre Methoden auf einer VMT abbildet, die nicht mit denen der DLL-Version dieser Klasse übereinstimmen.

Ja! Ich stimme voll und ganz mit dir überein (ich war es nicht, der die Originalfrage gestellt hat, ich habe versucht genau diese Tatsache zu begründen!)

Zitat:

Zitat von Elvis

Ein "passt scho'" akzeptiere ich hier nicht.

Auch hier volle Zustimmung von mir!

Selbst wenn jemand auf die Idee käme ein "passt scho'" zu akzeptieren wird er damit eben irgendwann ganzgehörig auf die Nase fallen und dann nicht mehr wissen warum (solche selbstgeschaffenen "Fehler" sind nicht so einfach zu finden)

Zitat:

Zitat von Elvis

Ich predige hier schon lange wiederholt eine einfache und sehr elegante Möglichkeit um Objekte in DLLs benutzen zu können, ohne sich sinnlos an eine RTL- oder Delphiversion zu fesseln: Interfaces.
Man kann sich eine einfache Verpackung für einebestehende TSTrings-Referenz bauen, die man problemlos als Interface an eine Delphi/FPC- -DLL schicken kann (auch C++, wenn WideString anstatt AnsiString benutzt wird).

... Code gelöscht (siehe Originalpost) ...

Das ist wirklich eine sehr interessante Möglichkeit, vor allem im Hinblick auf die Verwendung von Delphi-Objekten in anderen Sprachen. Muss ich mir mal merken. Danke für den Tipp!

Ciao,
Ralf

[QuickAndDirty]

Zitat:

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:

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:

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.

[Ralf Kaiser]

Zitat:

Zitat von QuickAndDirty

Hi,

Zitat:

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.

Ich reagiere auf solche Patches immer extrem allergisch. Als ich in der Firma anfing in der ich jetzt noch arbeite habe ich ein paar Projekte von einem Vorgänger übernommen der nicht mehr verfügbar war (ich konnte ihn also nichts fragen). Dieser Mensch hatte, weil er es nicht besser wusste einfach einige Teile der VCL (damals noch D1) gepatcht und dies nirgendwo dokumentiert.

Solange man die Projekte auf seinem Ex-Rechner kompillierte funktionierte alles tadellos. Nur auf meinem Rechner wollten einige Sachen einfach nicht klappen was logisch war, hatte ich doch ein frisch installiertes System.

So entwickelt man gegen solche Praktiken schnell eine extreme Allergie!!

[QuickAndDirty]

@Algi001:
Ich dich kann ich verstehen. Es war auch mehr ein experimenteller Patch, nur um zu sehen ob das geht, hab dabei viel gelernt.
Im Übrigen sind VCL Patches durchaus sinnvoll du solltest da keine allergischen
Reaktionen ausbilden. In unserer Firma wurde z.B. die DBtables von D3 bis D7 immer gepatched,
weil es scheinbar nicht möglich war das die Borländer einen Bug beseitigten, der in seltenen Fällen auftrat.

Da wir "leider"(!!!) sehr viele Toolbibliotheken verwenden ist bei uns das Einrichten einer Arbeitsumgebung sowieso auf mehreren Seiten Dokumentiert.
Es dauert 1-2 Tage um eine Arbeitsplatz einzurichten, deswegen machen wir alles auf VMs.