bibliothek: string vector usw... ueber dll/do grenzen



  • hallo leute und frohe weihnachten,

    kennt jemand eine ausgereifte bibliothek die string, vector usw. beinhaltet und die man ueber dll/so grenzen verwenden kann ? am besten waere es wenn sie auch mit der STL zusammenarbeiten koennte.

    Meep Meep



  • Man kann string, vector u.ä. über Dll/so Grenzen verwenden!



  • kann man nur unter bestimmten voraussetzungen. dll mit VC2010 und die exe mit VC2015 kompilieren und schon kanns krachen. unbrauchbar. ich will ja noch jede dll oder exe neu kompilieren muessen, wenn ich eine neue software entwickel und auf bestehenden code in dlls zurueckgreifen will



  • Ja, und wenn du dir jetzt mal überlegst, was das konkrete Problem dabei ist, sollte dir auch klar werden, dass es keine solche Bibliothek geben kann.



  • warum sollte es sowas nicht geben koennen ?
    schliesslich kann man heute noch immer dll dateien verwenden die vor 10 jahren geschrieben worden sind.
    ich dachte da auf eine bibliothek die z.b. auf COM ähnlicher technologie aufbaut.
    also z.b. rein virtuellen interfaces.

    Meep Meep



  • Solabge der C++ Standard kein einheitliches ABI vorschreibt, wird das auch nicht funktionieren. Ein weiteres Problem sind verschiedene Laufzeitbibliotheken. Bei C-Schnittstellen sind diese Probleme nicht so groß.



  • Du kannst eine Dll mit einer C-Schnittstelle schreiben. Die wird höchstwahrscheinlich auch über mehrere Compilergeneration funktionieren.

    Nochmal: denk darüber nach, was das eigentliche Problem ist.



  • manni66 schrieb:

    Du kannst eine Dll mit einer C-Schnittstelle schreiben. Die wird höchstwahrscheinlich auch über mehrere Compilergeneration funktionieren.

    Nochmal: denk darüber nach, was das eigentliche Problem ist.

    ehrlich gesagt weiß ich nicht worauf du hinaus willst.
    die speicherverwlatung ? die ist kein problem.

    oder woran denkst du ?

    Meep Meep



  • Du musst doch irgendeine Vorstellung davon haben, warum du die Dll neu übersetzen musst.



  • Die ABI ist doch nicht Problem. Wenn die ABI bei beiden Modulen kompatibel ist, ist ja erstmal zur Build-Zeit alles i.O.

    Das Problem ist die Runtime! Wenn du in Modul A die Runtime X benutzt, und in Modul B die Runtime Y benutzt, wird das jeweils andere Modul nicht die Objekte des anderen Moduls korrekt verwalten können. Das funktioniert nur, wenn man das jeweilige Modul die Objekte erstellen (new) und wieder löschen (delete) lässt. Also das, was die COM-Spec (auch eine ABI für OO-Sprachen) von Windows vorschreibt. Da kann eine DLL sogar in Delphi erstellt worden sein, und du kannst diese von C++ aus benutzen (und natürlich auch umgekehrt, Delphi-Spiele können DirectX benutzen, obwohl DX in C++ ist).

    Aber das COM-Modul hat die Factory bzw. Object-Pool, und dann ist alles in Butter.

    Das ObjectPool-Pattern kann man natürlich auch auf alles andere (ohne COM/ActiveX) anwenden.

    Was ich mich nur Frage: warum benutzt du nicht die C++-Std-Lib? Diese ist natürlich auch über DLL-Grenzen hinweg benutzbar... wenn du das Object Pool Pattern anwendest. Wobei du das Object Pool Pattern nicht 1:1 umsetzen musst, kannst die Objekte trotzdem endgültig deleten...


Log in to reply