3. Pluginsystem Plattfiorumunabhängig?

Pluginsystem Plattfiorumunabhängig?

  • M

    Hallo!

    Was gibt es für Möglichkeiten, ein Pluginsystem zu designen, welches Plattform unabhängig funktioniert? Unter windows alleine geht das ja gut mit LoadLibrary etc.
    Ich kenn mich zB mit linux kaum aus, weiß nur, da gibts anstat dll .so
    aber wie man die lädt usw. kA. und von Mac weiß ich gar nichts.

    Also, gibts vielleicht schon vorgefertige libs, die sozusagen die Funktionen aus plugindateien (dll, so, mac-äquivalent) ziehen und ale funkitonspointer zurück geben oder so? Oder wie macht man das sonst mit plugins unter verschiedenen plattformne?

    0
  • D

    da hast du trauer. Einzige Möglichkeit wäre nen Scriptinterpreter.
    Beispielsweise lua oder python.

    0
  • ?

    Oder komm auf die gute seine der Macht: Java!

    0
  • ?

    Stichwort dlopen

    0
  • R

    Das ist recht schnell selbst implementiert. Unter Unix/Linux/OSX gibt es [man: dlopen(2}](http://man.cx/dlopen(2}) dafür.

    Ich habe mal so was geschrieben. Wenn ich es finde, kann ich es hier posten.

    0
  • A

    Hem, dynamische Libs als Plugins ist eine Möglichkeit. Es gibt ja auch andere, z.B. Konzepte wie es COM und ActiveX machen (ich meine nur die Konzepte!). Du könntest Corba verwenden, damit ein Plugin mit einem Programm reden kann (ist das, was COM/ActiveX machen). Oder Sharedmemory (shmem von boost) könnte auch eine Lösung sein. Das sind alles Konzepte die sich von Fall zu Fall eignen.

    Eine kostenlose Corba-Implementierung: http://www.mico.org/

    Wenn du Plugins haben willst, die mehr oder weniger simpel sind, könntest du einfach Python oder Lua anbinden. Die beiden haben auch wieder ihre Vor-/Nachteile. Python ist z.B. objektorientiert und boost bietet sogar eine Unterstützung an, mit der Du deine Programme mit Python erweitern lassen kannst. Python ist aber relativ langsam.
    Lua ist dagegen sauschnell (als Scriptsprache) und hat ne eigene VM, die du in deine C/C++-Programme einbetten kannst. Ist aber wiederrum nicht objektorientiert.

    Es gibt also sehr viele Lösungswege um ein Plugin-System zu realiesieren. Bei allen Lösungen mußt du aber immer etwas Hand anlegen.

    0
  • M

    hm... also mit corba kenn ich mich nich aus, auch kaum mit com, also eigentlich auch nich. sah auf den ersten Blick auch ziemlich kompliziert aus 🙂 naja, werd mich da vielleicht mal mit befassen.

    es geht um folgendes. Ich habe ein programm, welches Daten aus Datenbanken auf eine bestimmte weise visualisieren soll. klappt auch ganz gut. allerdings liegen die daten in den datenbanken in verschiedenen formaten vor. also muss man sozusagen einen vermitler haben, welcher daten aus den datenbanken aufbereitet, damit sie angezeigt werden können, denn das Programm weiß zB nich, wie die tabellennamen sind, die die felder heißen usw. Deshalb dachte ich an ein Pluginsystem, mit dem man dann schnell die datenbanken welchseln kann, ohne alles neu zu machen.

    Könnte sein, dass ich das ganze mit Lua hinbekomme. oder Python (interessiert micih sowieso schon immer 🙂 ). Oder ich versuchs mit LoadLibrary, dlopen. wie ist das pendant zum mac von dlopen?

    das ganze schient jedenfalls sehr spannend zu werden 🙂
    Danke für eure Antworten 🙂
    Maxi

    0
  • S

    Du brauchst kein Python, Lua, COM, Corba oder sonst was.

    Du erstellst einfach eine shared library ("so" in linux, "dll" in windows,...) und abstrahierst das Laden etwas. So wahnsinnig unterschiedlich ist das nicht: LoadLibrary & Co versus dlopen & Co.

    Doof wirds nur wenn du mehr exporten willst als nur rohe Funktionen: zB Objekte. Dann wird es haesslich und du brauchst entweder immer den selben Compiler oder du musst eben serialisieren/deserialisieren.

    Also: solange du nur C code exporten willst, ists kein Thema.

    Du musst natuerlich jedes plugin fuer jede plattform kompilieren - aber das sollte ja klar sein.

    0
  • M

    naja...
    also wenn ich den code shcon in c++ schreiben kann, dann will ich auch mit klassen und pipapo. ich wollte mir dann eine abstrakte Klasse

    cDataLoader schreiben, die das Interface bereitstellt, und im Plugin liegt die Implementierung drin. Aber eigentilch... hab da grad ne Idee. Geht sowas?

    // hauptprogramm
class Loader()
{
Loader();
bool Load() = 0;
};

Loader* (func)(); // oder so ähnliche syntax für funcionpointer func :)
func = dlsym("GetLoader", ...);

// Objekt aus Dll/so holen.
Loader* loader = func();

// plugin:
class DB1Loader : public Loader
{
bool Load() { return true; };
};

extern "C"
{
Loader* GetLoader() { return new DB1Loader; };
}

    also dass ich das interface für alle pölugins gleich mache (is ja eh klar)
    und dann nur die eine funktion in der dynlib extern-c mache und über diese funktion an ein objekt des richtige lodaers komme. funktioniert dann die polymorphie noch, auch wenn die klasse in anderem speicher liegt?
    Dass mit gleichem compiler gearbeitet wurde, setz ich mal voraus...
    Maxi

    0
  • S

    Das geht nicht gut, weil das Objekt Model von C++ nicht fest definiert ist. Einzelne Compiler haben da Unterschiede. Also wenn du nicht alle Plugins mit dem selben Compiler erstellen willst, musst du n anderes System verwenden als du jetzt vor hast.

    Ansonsten funktioniert dein Ansatz.

    0
  • M

    hm... also habs ausprobiert, unter windows funktioniert das jednfalls 🙂 mit vc express...

    naja... ich denk ich mach es erstmal so, ich seh ja auch nich, dass jemand anderes dafür plugins schreiben wird (ok, das is eig der sinn von plugins 🙂 ), und wenn dann muss er eben auch vc2005 nehmen oder eben gcc unter linux dann.

    0
Anmelden zum Antworten