3. C++ - dynamische library

C++ - dynamische library

  • X

    Hallo zusammen,

    ich meine mich zu erinnern, dass die Definition von Funktionen innerhalb einer dll nur für C definiert ist und so kompilerübergreifend funktioniert.
    Als einfache statische Funktionen mit Pod als Parameter bzw. Rückgabe-Typen.
    Also zumindest, weiß ich diese definiert sind. Wie schaut es aus, wenn ich ein Objekt übergebe, das Member-Funktionen hat? Ist dieser Fall auch definiert?
    Oder wenn das Objekt dann virtuelle Funktionen hat.
    Wo ist die Grenze?

    Hat irgendjemand evtl. einen hilfreichen Link?
    Solange man nur einen Kompiler verwendet, funktioniert ja so ziemlich alles...
    Aber wo sind die Grenzen, wenn man mehrere Compiler verwendet?

    Gruß,
    XSpille

    0
  • B

    Du hast es schon ganz richtig erkannt: Alles, was über C hinausgeht, kannst du vergessen, zumindest beim Visual Studio. Der GCC unter Linux ist da etwas ABI-kompatibilitätsfreundlicher.

    0
  • X

    thx 😞

    Genau das hatte ich befürchtet 🙄

    0
  • K

    Es gibt das Itanium C++ ABI fuer 64-Bit Systeme. Nur ein einziger grosser Compilerhersteller haelt sich nicht daran. Rate mal, welcher.

    0
  • X

    Perfekt! 👍

    Wer nicht integriert werden möchte, ist selber schuld 😉

    0

  • Unter Windows: COM bzw. WinRT, damit bist du dann sogar sprachunabhängig...

    0

  • Unter Windows funktioniert nicht nur COM, sondern auch das Übergeben von Zeigern auf "COM-artige" Interfaces/Objekte compilerübergreifend (allerdings ohne "echtes" COM dann nicht mehr sprachunabhängig). Zumindest mit allen Compilern die COM "können", und das können soweit ich weiss irgendwie alle relevanten (MSVC, Intel, MinGW -- vermutlich auch Borland).

    Wobei "COM-argtig" jetzt heisst...
    * Die Klasse ist abstrakt und hat (ausschliesslich) "public virtual pure" Memberfunktionen, die alle __declspec(stdcall) sind
    * Die Klasse hat keinen Konstruktor und keinen Destruktor (auch keinen virtuellen Destruktor)
    * Die Klasse darf von genau einer anderen solchen Klasse public abgeleitet sein, und sonst keine Basisklassen haben
    * Die Klasse besteht aus sonst nichts, d.h. keine Datenmember o.ä.

    Und natürlich muss man bei den Parameter- und Returntypen aufpassen, d.h. std::string übergeben ist logischerweise nicht drin.

    Irgendwelche COM-Interfaces wie IUnknown müssen aber nicht implementiert werden.

    dynamic_cast geht natürlich nicht, aber da kann man ja drum-rum arbeiten, wie es auch COM mit IUnknown::QueryInterface macht.

    0
Anmelden zum Antworten