Plugin plattformunabhängig laden
-
Hallo,
gibt es eine möglichkeit, plugins plattformunabhängig zu laden? Ich habe nur dlopen gefunden, das unter linux funktioniert, und unter windows verwendet man laut meinen recherchen loadlibrary aus der winapi.
Gibts irgendeine projekt, das beide kapselt? Boost.extension ist leider noch in der sandbox.
Danke!
Mfg,
-
Du kannst ja Boost.Extension trotzdem nutzen. Oder selber schreiben und bei Boost.Extension abgucken. Der Code ist ja nicht so kompliziert.
-
-
Dann werd ich boost.extension nutzen, danke!
Qt passt mir leider nicht so in mein konzept, aber danke für den vorschlag!
-
Schau mal hier: https://fedorahosted.org/OpenAPC/browser/liboapc
Die liboapc kapselt alle möglichen betriebssystemabhängigen Funktionen - inclusive dlopen() - und bietet nach oben hin ein einheitliches Interface. Derzeit werden wohl Windows, Linux und QNX unterstützt.
-
@WaHoooo
Danke für den link! Direkt verwenden kann ich das jetzt nicht, aber es hilft mir zumindest weiter, wie ich sowas selber basteln könnte!
-
Steini79 schrieb:
Direkt verwenden kann ich das jetzt nicht
Naja, Make- und Projektfiles wären dort eigentlich auch alle vorhanden
-
Auch wenn ich von Poco grundsätzlich nichts halte, haben sie einen ganz brauchbaren ClassLoader.
-
Und was hat ein Classloader jetzt mit den C-Symbolen in einer Shared Library zu tun?
-
Wer sagt, dass das nicht genau das ist, was er möchte?
-
Die Spezifikation für Shared Libraries: Wenn diese Klassen exportiert, ist das schlichtweg Pfusch, da diese nur als C-Funktionsinterface taugen (und ansonsten compilerabhängig sind, was bei 3rd Party Libraries ausgesprochen bescheuert wäre).
-
Und du hast keine Ahnung. Bevor du dich noch weiter aus dem Fenster lehnst, siehst du dir die Implementierung in Poco an.
-
Zitat aus der Poco-Doc:
All classes loaded with a specific class loader must be subclasses
of a common base class. Poco::ClassLoader is a class template
that must be instantiated for the base classUnd jetzt darfst du mir zwei Dinge erklären:
1. Wie kann man damit 3rd Party Libraries laden, die sich eben nicht von Poco::ClassLoader ableiten?
2. Wo ist die Struktur von Klassen für das Linker-Binärformat verbindlich spezifiziert, so dass es ohne seltsame Probleme möglich ist, Objekte in portabler Form per Shared Libray Interface zu übergeben?
Jetzt kommst du...
-
@1: Er will doch nur eigene Libraries laden, folglich kann ihm das egal sein.
@2: Braucht es nicht. Poco sucht auch nur Funktionen über dlopen/LoadLibrary und kapselt das ganze in ein praktisches Interface. Hättest du gesehen, wenn du einen Blick über deren Source geworfen hättest.
-
314159265358979 schrieb:
@2: Braucht es nicht. Poco sucht auch nur Funktionen über dlopen/LoadLibrary und kapselt das ganze in ein praktisches Interface. Hättest du gesehen, wenn du einen Blick über deren Source geworfen hättest.
Und warum redest du dann die ganze Zeit vom Poco-Classloader wenn du doch nur Poco::SharedLibrary meinst?
Auweia, ich glaube, ich diskutiere hier mit dem Forentroll...
-
Das ist kein Forentroll - das ist Pi
-
WaHoooo schrieb:
314159265358979 schrieb:
@2: Braucht es nicht. Poco sucht auch nur Funktionen über dlopen/LoadLibrary und kapselt das ganze in ein praktisches Interface. Hättest du gesehen, wenn du einen Blick über deren Source geworfen hättest.
Und warum redest du dann die ganze Zeit vom Poco-Classloader wenn du doch nur Poco::SharedLibrary meinst?
Auweia, ich glaube, ich diskutiere hier mit dem Forentroll...
Ich meine doch den ClassLoader, der tut auch nur genau das.
-
Pi ist immer wieder fuer einen Lacher gut
-
314159265358979 schrieb:
@2: Braucht es nicht. Poco sucht auch nur Funktionen über dlopen/LoadLibrary
314159265358979 schrieb:
Ich meine doch den ClassLoader, der tut auch nur genau das.
-
Meine Fresse. Euch Vollidioten muss man echt alles erklären. Poco lädt HINTER DEN KULISSEN auch nur Funktionen, darauf baut der CLASSLOADER auf, der KLASSEN lädt. Damit sollten es auch minder von Intelligenz bewanderte Lebewesen wie ihr verstehen.