dlsym rückgabewert casten
-
314159265358979 schrieb:
Donggger schrieb:
Wenn du wirklich Objekte über ausgelagerte Programmkomponenten ziehen willst und eine saubere Lösung suchst, darfst du generell keine Shared Library verwenden, sondern müsstest dich beim COM-Interface (nicht zu verwechseln mit der seriellen Schnittstelle) bedienen. Und das gibt es nur bei Windows.
Schwachsinn. Das geht mit dem Posix-Interface wunderbar und wohldefiniert.
Nope. Geht leider nicht so einfach. Weil wenn du zB den gcc verwendest und ich den llvm dann tut das ganz dicke aua machen wenn wir versuchen C++ Objekte zu sharen
Aber insofern hast du recht, es ist wohldefiniert was passiert: naemlich ein PENG BUMM BAENG.
C++ Objekte ueber Modulgrenzen hinweg sharen ist deshalb doof, weil C++ keine definierte ABI hat. Da gibt es viele Fallstricke deshalb ratet man davon ab.
Wo es Sinn machen kann ist innerhalb eines Projektes - wenn man das Buildenvironment kontrolliert.
-
Als alternative kann man ja auch eine Skriptsprache für die Module verwenden, z.B. Python, Lua oder AngelScript
-
Shade Of Mine schrieb:
C++ Objekte ueber Modulgrenzen hinweg sharen ist deshalb doof, weil C++ keine definierte ABI hat. Da gibt es viele Fallstricke deshalb ratet man davon ab.
Wo es Sinn machen kann ist innerhalb eines Projektes - wenn man das Buildenvironment kontrolliert.
Das Build-Environment kann man auch toll für Plugins kontrollieren. z.B. indem man es vorschreibt, evtl. sogar gleich passende Makefiles/Solution-Files mitliefert.
Ich verstehe einfach nicht wieso manche immer meinen, dass etwas was sie für ihr Projekt nicht brauchen/brauchen können (bzw. einfach nicht *wollen*), auch ganz allgemein eine schlechte Idee sein muss.
Es gibt einige Projekte die recht erfolgreich Plugins mit C++ Schnittstelle verwenden. Als ein Beispiel wäre foobar2000 zu nennen.
Shade Of Mine schrieb:
Nope. Geht leider nicht so einfach. Weil wenn du zB den gcc verwendest und ich den llvm dann tut das ganz dicke aua machen wenn wir versuchen C++ Objekte zu sharen
S.o.: nimm halt einfach nicht LLVM sondern das was das Programm vorschreibt. Mir ist vollkommen klar was du meinst, aber gleichzeitig vollkommen unklar wieso das ein generelles Problem sein sollte.
-
314159265358979 schrieb:
hustbaer schrieb:
Welches Posix-Interface meinst du
Na das, von dem wir (fast) die ganze Zeit reden: dlopen, dlssym, ...
dlopen, dlssym etc. tragen jetzt weder besonders viel dazu bei dass es geht, noch arbeiten sie irgendwie dagegen.
Damit kann man halt Zeiger per Namen aus nem SO rausholen, mehr nicht. (EDIT: und das SO vorher erstmal laden natürlich /EDIT)Ob man problemlos mit C++ Interfaces arbeiten kann oder nicht, wird davon nicht wirklich beeinflusst - da sind andere Dinge wichtig.
Daher dachte ich du meinst vielleicht die Itanium C++ ABI - die aber mit Posix rein gar nix zu tun hat. Weil ich mir aber nicht sicher war, dachte ich mir ich frag lieber mal nach...
-
hustbaer schrieb:
S.o.: nimm halt einfach nicht LLVM sondern das was das Programm vorschreibt. Mir ist vollkommen klar was du meinst, aber gleichzeitig vollkommen unklar wieso das ein generelles Problem sein sollte.
Ein Problem per se ist es nicht. Aber es sind sehr wenige Situationen wo C++ Interfaces hier Sinn machen. Denn C++ Interfaces verlangen, dass man das Build Environment kontrollieren kann. Wenn man das kann, super - dann ists kein Problem.
Nur oft kann man das nicht. Deshalb lieber C++ in Shared Objects mit vorsicht behandeln. Wenn man aber natuerlich weiss was man tut, ists kein Problem.
-
@Shade
OK, dann sind wir uns ja einig
@hutzlwutzl
Unter Windows gibt es DLLs statt Shared Objects und die Funktionen LoadLibrary/GetProcAddress statt dlopen/dlsym.
Wobei Windows DLLs und Linux/... Shared Objects einige Dinge etwas anders regeln.
