Plugin plattformunabhängig laden

314159265358979

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 speciﬁc class loader must be subclasses
of a common base class. Poco::ClassLoader is a class template
that must be instantiated for the base class

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

314159265358979

@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

314159265358979

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.

314159265358979

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.

Meine Fresse.

LOL

Euch Vollidioten muss man echt alles erklÃ¤ren.

ROFL

Poco lÃ¤dt HINTER DEN KULISSEN auch nur Funktionen, darauf baut der CLASSLOADER auf, der KLASSEN lÃ¤dt.

ROFLÂ²

Damit sollten es auch minder von Intelligenz bewanderte Lebewesen wie ihr verstehen.

*ROFLMAO* *luftholen* - so, geht wieder

Du hast ROFL³ vergessen

Ethon

Manchmal tut mir PI leid. Sucht euch/(dir ?) Hobbies.

Genau - lasst sie in Ruhe!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!(!)

TyRoXx

Steini79 schrieb:

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,

Hast du schon eine Skriptsprache wie Lua in Betracht gezogen?

314159265358979 schrieb:

Poco lädt ... Funktionen, darauf baut der CLASSLOADER auf, der KLASSEN lädt.

Also macht das Teil in etwas sowas:

myClass=(PocoClass*)(void (*funcPtr)(void*));

Wow! Das gehört eindeutig in die FAQ.

Steini79

Hmmm, sind alle ein bisschen erregt hier.

Erst einmal danke für alle antworten, ob hilfreich oder nicht ist egal, es sind zumindest schlagworte vorhanden, die mich weiter bringen/gebracht haben.

@TyRoXx

Über Lua habe ich mir noch keine gedanken gemacht, werde ich aber noch, danke!

Was ich bisher gemacht habe war, das ich mein programm über shared objects/dlls/etc. über ein vordefiniertes interface ala abstrakter basis klasse erweitere.

@Notch

Danke das du den beitrag in die breite gezogen hast...

Artchi

Lua ist als Scriptsprache wirklich super, aber wenn ich Plugins eh in C++ entwickeln würde, würde ich dann eine mächtigere OO-Scriptsprache nehmen: AngelScript ist speziell für C++ und man fühlt sich als C++ Programmierer gleich zu Hause.

Außerdem ist das Binding zwischen C++ und AngelScript viel einfacher und natürlicher als mit Lua, da Lua eine procedurale Scriptsprache ist. Und das Binding mit C++-Klassen eher ein Beinbruch ist, weil nicht von Haus aus keine OOP möglich ist.

Scripttsprachen können aber trotzdem nativen Code nicht ersetzen. Man kann mit Scriptsprachen halt wirklich nur das Hostprogramm "scripten", was man mit C++-Plugins nicht als Einschränkung hat. Evtl. ist also eine Scriptsprache auch nicht DIE Lösung. Oder das angedachte Plug-in-System war vorher overkill.