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?

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

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.

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

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.

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

Ansonsten funktioniert dein Ansatz.

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.