DLL ShareMem D2007 -> XE7?

[Mavarik]

Zitat von himitsu:

Bei VAR wird die Referenz unverändert reingegeben, da ist es egal.

Bei prodecure Test(S: WideString); wird aber eine 100%-Kopie des Strings erstellt, bei Aufruf der Prozedur.
Bei LongStrings (AnsiString/RawByteString/UTF8String und UnicodeString) wird einfach nur die Referenzzählung schnell hochgezählt, was praktisch nicht auffällt.

Bei prodecure Test(const S: WideString); passiert das nicht, da direkt mit der schreibgeschützten Referenz gearbeitet wird.

Ahh dann ist gut. Dachte schon VAR würde nicht gehen...
Was ist z.B. mit TObject... ? Das abgeleitete Object könnte ja in D2000 und XE7 unterschiedlich sein.

Mavarik

[himitsu]

Objekte grundsätzlich niemals über Modulgrenien (EXE/DLL) hinweg verwenden,
außer bei BPL, oder wo man selber die RTTI shared.

Zitat:

Das abgeleitete Object könnte ja in D2000 und XE7 unterschiedlich sein.

Ja, und es kann auch innerhalb der selben Version sich unterscheiden, abgesehn von den Änderungen durch Updates/Bugfixes.

TObject der DLL ist ein anderes als das TObject der EXE,
genauso bei allen anderen Klassen.

Wenn auf einer Seite ein Feld nicht benutzt wird, dann kann der Compiler das weglassen, womit dann alle nachfolgenden Adressen nicht mehr stimmen.
Der Offset nachfolgender Variablen verschiebt sich (aber nur in der einen RTTI) und auch die Position in der VMT verschiebt sich, bei virtuellen Methoden
und somit greift die andere Seite (EXE/DLL) mit ihrer eigenen RTTI auf was Falsches zu.

[Mavarik]

Zitat von himitsu:

Objekte grundsätzlich niemals über Modulgrenien (EXE/DLL) hinweg verwenden,
außer bei BPL, oder wo man selber die RTTI shared.

Zitat:

Das abgeleitete Object könnte ja in D2000 und XE7 unterschiedlich sein.

Ja, und es kann auch innerhalb der selben Version sich unterscheiden, abgesehn von den Änderungen durch Updates/Bugfixes.

TObject der DLL ist ein anderes als das TObject der EXE,
genauso bei allen anderen Klassen.

Wenn auf einer Seite ein Feld nicht benutzt wird, dann kann der Compiler das weglassen, womit dann alle nachfolgenden Adressen nicht mehr stimmen.
Der Offset nachfolgender Variablen verschiebt sich (aber nur in der einen RTTI) und auch die Position in der VMT verschiebt sich, bei virtuellen Methoden
und somit greift die andere Seite (EXE/DLL) mit ihrer eigenen RTTI auf was Falsches zu.

Also für alles was nicht (Byte,Word,Integer,Pointer,Widestring) ist einen "schönen" Wrapper bauen...

z.b. alles in einen Buffer "knallen" und den Pointer auf den Buffer übergeben...

Mavarik

[himitsu]

Oder ein IInterface um das Objekt drumrum (also auch ein Wrapper ), da dort das Interface feste Indize besitzt (wenn man überall die selbe Definition verwendet) und es dann in jedem Modul eine passende Übersetzung für Interface<->Klasse gibt.

Und natürich nur statische Typen verwenden, also kein PChar, Char usw., sondern PAnsiChar, PWideChar usw.
Für Integer/NativeInt/Pointer würde es zwar auch gelten, aber da man eh keine 32-Bit-DLL in eine 64-Bit-EXE rein bekommt, und andersrum ebenfalls nicht, stört es hier nicht.

[Mavarik]

Zitat von himitsu:

Oder ein IInterface um das Objekt drumrum (also auch ein Wrapper ), da dort das Interface feste Indize besitzt (wenn man überall die selbe Definition verwendet) und es dann in jedem Modul eine passende Übersetzung für Interface<->Klasse gibt.

emm dazu nochmal auf deutsch bitte.

Natürlich nutze ich ein Interface.

Delphi-Quellcode:

    IFooDll = Interface
      ['{23763801-630D-4389-B214-398804635CA1}']
      Procedure Test(Var S : WideString);
      Function ShowPanel(ParentWnd:hwnd;R:TRect):hWnd;stdcall;
    End;

Und übergebe das Interface an die DLL

Delphi-Quellcode:

Procedure SetInterface(Var DLL:IFooDll);
begin
  DLL := TFoo.Create;
end;

Exports
  SetInterface;

Welchen Vorteil - den ich noch nicht gesehen habe - habe ich dadurch auch noch?

Mavarik