3. vtable layout

vtable layout

  • C

    Hallo,
    ich hab zur Zeit ein kleines Projekt, bei dem ich compilierte Objekte von anderen Programmierern über den Windows-Dll-Mechanismus zur Laufzeit einbinden will.
    (dazu exportiert die dll eine factory funktion, die ein Objekt einer Klasse erzeugt,
    die der Programmierer von einer virtuellen Basisklasse abgeleitet hat.
    siehe z.B. http://aegisknight.org/cppinterface.html)

    Leider verursacht das Probleme, weil anscheinend das vtable layout von G++ und MSVC6.0 compilierten Klassen nicht identisch ist
    -> es werden die falschen Methoden aufgerufen, wenn das Hauptprogramm und die Dlls mit unterschiedlichen Compilern compiliert werden

    Ist das layout der vtable (also die Reihenfolge, in der die pointer gespeichert werden) irgendwie standartisiert?
    Weiss jemand, wie's G++ und MSVC6 machen?
    Gibts bei den beiden Compilern die Möglichkeit, das layout irgendwie zu beeinflussen, sodass man was gemeinsames findet?
    Was gibts noch für Möglichkeiten, ohne großen Aufwand Objekte compilerunabhängig zu exportieren?

    Vielen Dank schonmal im voraus für die Antworten...
    C14

    0
  • K

    C14 schrieb:

    Ist das layout der vtable (also die Reihenfolge, in der die pointer gespeichert werden) irgendwie standartisiert?

    Allgemein: nein.

    Es kann sogar von Version zu Version unabhängig sein. Zu den anderen Fragen weiß ich keine Antwort, bezweifle aber, dass man es beeinflussen kann. Wofür gibt es schließlich Exporttabellen? vtables sind Implementierungsdetails, wieso sollte man hierauf Einfluss haben?

    Was gibts noch für Möglichkeiten, ohne großen Aufwand Objekte compilerunabhängig zu exportieren?

    COM z.B. ...

    /EDIT: Typo.

    0

  • Was gibts noch für Möglichkeiten, ohne großen Aufwand Objekte compilerunabhängig zu exportieren?

    COM z.B. ...

    😃
    Hier har jmd. Sinn für Humor *g*

    0
  • A

    Wieso? COM-Objekte können nicht nur C++ Compiler unabhängig genutzt werden, sogar Sprachunabhängig. Z.B. kann ein VB-Programm COM-Objekte erzeugen, und diese können von einem C++ Programm genutzt werden. Ja, sogar Delphi-Programme können das. Die Kombinationen sind schlichtweg egal.

    Und was den Aufwand angeht: es ist super easy COM- bzw. ActiveX-Objekte zu erzeugen. Oder hast du kein VC++ mit ATL?

    0

  • Artchi schrieb:

    Und was den Aufwand angeht: es ist super easy COM- bzw. ActiveX-Objekte zu erzeugen. Oder hast du kein VC++ mit ATL?

    Äh.
    Ich hab selbst schon mit MSVC (7.1) und attributed C++ DCOM Geschichten gemacht. Der ganze wirklich wahnsinnig öde IDispatch Scheiss fällt dadurch zwar weg, aber einfach und vor allen "wenig Aufwand" würde ich das nicht gerade nennen.

    Kommt natürlich auch drauf an was man machen will, ein kleines COM Objekt mit 5-10 einfachen Funktionen int 1-2 Interfaces ist schnell Programmiert, aber wenn dann mal IEnumXXX Dinge dazukommen, Aggregation, Events, Output Parameter etc. - dann ... naja.

    ----

    Und dann Clientseitig... ist z.B. nicht gerade lustig wenn man die ganze Zeit Interfaces zwischen Threads (bzw. Apartments halt) herummarschallen muss. Jack. MTA kann man auch meistens vergessen, zumindest sollte der GUI Thread nicht zum MTA gehören, sonst geht kein ActiveX Control mehr, und Serverseitig nen den free threaded marshaller zu unterstützen ist auch nicht immer so einfach.

    0
Anmelden zum Antworten