dlsym rückgabewert casten

[hustbaer]

Donggger schrieb:

Das KANN gut gehen, muss aber nicht. D.h. unter Umständen funktioniert es, unter Umständen reicht aber auch schon irgend eine Compileroption, die bei Plug-In und Hauptprogramm anders gesetzt ist, um dir die seltsamsten Effekte zu bescheren. Von unterschiedlichen Compilerversionen ganz zu schweigen...

Und warum genau soll er jetzt nicht auf mich hören? Willst du ihn lieber weiter in die falsche Richtung laufen lassen, bis ihm seine Objekte über die C-Schnittstelle irgendwann viel, viel später um die Ohren fliegen?

Die Berichte von auf Grund von unterschiedlichen Compiler-Switches explodierten Programmen sind stark übertrieben.

Es gibt andere Dinge die schon weniger egal sind, wie z.B. die Sache mit unterschiedlichen CRT Versionen, Heap etc.
Lässt sich aber auch alles regeln.

Es gibt Fälle wo C-Interfaces angesagt sind, und es gibt Fälle wo C++ Interfaces angesagt bzw. zumindest vollkommen OK sind. Die Grundsätzliche "C++ Interfaces sind pöse" Panikmache kann ich nicht ganz nachvollziehen.

[Donggger]

hustbaer schrieb:

Die Grundsätzliche "C++ Interfaces sind pöse" Panikmache kann ich nicht ganz nachvollziehen.

Na dann schreib' mal eine DLL mit Visual Studio die Objekte nutzt. Und viel Spaß dann mit dem Support für deine Kunden, die eine Applikation mit MingW compilieren und denen deine DLL bei jedem Zugriff um die Ohren fliegt.

Oder auch viel Spaß mit denen, die zwar Visual Studio verwenden, aber einen Debug-Build verwenden wollen. Erkläre denen mal, dass du keinen Debug-Build deiner DLL auslieferst und sie deswegen ihre Applikation auch nur als Release-Build debuggen können.

[hustbaer]

Komm lass gut sein und troll hier nicht rum.
Wenn du diskutieren willst dann zitier ordentlich

Es gibt Fälle wo C-Interfaces angesagt sind, und es gibt Fälle wo C++ Interfaces angesagt bzw. zumindest vollkommen OK sind. Die Grundsätzliche "C++ Interfaces sind pöse" Panikmache kann ich nicht ganz nachvollziehen.

[Steini79]

Danke an alle für die infos! Das hilft mir weiter.

@Donggger

Der vollständigkeit halber würde ich auch gerne deine argumentation verstehen, dazu müsste ich aber wissen, wie du die sache mit anstatt mit dlopen/dlsym lösen würdest?

[Donggger]

Steini79 schrieb:

dazu müsste ich aber wissen, wie du die sache mit anstatt mit dlopen/dlsym lösen würdest?

Den Ersatz für dlopen()/dlsym() den du suchst, gibt es nicht. Wenn es um Shared Libraries geht, kannst du nur diese Funktionen verwenden und du kannst dir nur C-Funktionspointer mit C-Datentypen als Parameter zurückgeben lassen.

Der springende Punkt ist: Shared Libraries sind genau dafür gedacht, für Objekte waren sie nie vorgesehen. 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.

[314159265358979]

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.

[hustbaer]

@Donggger
Du verwechselst "sauber" mit "so flexibel wie möglich".
Es ist nichts unsauberes daran einen Compiler (plus evtl. nötige Einstellungen) vorzuschreiben.
COM funktioniert ja auch nur weil alle (relevanten) Windows-Compiler sich an das "COM kompatible" VTable Layout von MSVC halten.
MS verwendet sogar im Kernel-Mode diverse "virtuelle" Interfaces.

Das selbe kann man auch schön mit GCC unter Linux/BSD/... machen. Wird auch gemacht. Funktioniert auch gut.

Es ist natürlich nicht so flexibel wie ein reines C-Interface, weil es eben gewisse Restrictions bezüglich verwendbarer Compiler etc. bedeutet, aber wie schon gesagt: es ist nichts "unsauberes" daran.

[hustbaer]

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.

Welches Posix-Interface meinst du

[314159265358979]

hustbaer schrieb:

Welches Posix-Interface meinst du

Na das, von dem wir (fast) die ganze Zeit reden: dlopen, dlssym, ...

[hutzlwutzl]

314159265358979 schrieb:

hustbaer schrieb:

Welches Posix-Interface meinst du

Na das, von dem wir (fast) die ganze Zeit reden: dlopen, dlssym, ...

Heißt das, unter Windows gibt es keine sichere/saubere/... Lösung?

[314159265358979]

Nö, hab ich das irgendwo geschrieben? -.-

[Shade Of Mine]

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.

[pyhax]

Als alternative kann man ja auch eine Skriptsprache für die Module verwenden, z.B. Python, Lua oder AngelScript

[hustbaer]

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.

[hustbaer]

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...

[Shade Of Mine]

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.

[hustbaer]

@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.