Grundüberlegungen zu einem Plugin System

DannyD

Hallo,

ich bin noch recht neu im C++ Umfeld und plane derzeit ein Plugin System für eine Anwendung. Die Plugins sollen in DLL-Form in das Hauptprogramm eingebunden werden, jedoch bin ich darauf angewiesen innerhalb der Plugins diverse Klassen des Hauptprogramms zu verwenden. Jetzt stellt sich mir die Frage, wie ich das am besten konzipiere, ohne Teile des Hauptprogramms in DLLs auszulagern (würde gerne darauf verzichten). Gibt es eine Möglichkeit, das System so aufzubauen, dass ich meinen eigenen Code nicht in Libraries verlagern muss und den Plugin Entwicklern trotzdem Zugriff auf eigene Datentypen gewähre?

Maxi

Hast du schonmal überlegt, dein Plugin als Skriptsprache zu realisieren?
zB in python oder lua?

Ansonsten musst du deine Anwendungsklassen von abstrakten Basisklassen ableiten. Den pluginentwicklern gibst du dann die header der abstrakten Klassen. Über polymorphe Zeiger können plugins dann auf die anwendung zugreifen.

Allerdings ist dann das Problem, dass Plugin und Anwendung mit exakt den gleichen compilereinstellungen kompiliert werden müssen, da sonst die vtables in dll und exe nicht übereinstimmen.
Und das ist zeimlich mies für pluginentwickler.

Dritte möglichkeit ist es, aus der anwednung eine struktur mit ganz vielen funktionszeigern zu exportieren, mit denen dein plugin auf die daten zugreifen kann.

Bei dem Wikipediaartikel zu DLL der Abschnitt "Einbinden von DLLs zur Laufzeit" damit würde ich das machen.

DannyD

Die Möglichkeiten eins und drei fallen schonmal weg. Die Zweite kam mir schon in den Sinn, aber ich weiß nicht, ob es sinnvoll wäre, für jede Klasse eine eigene abtrakte Klasse zu schreiben. Ich denke es wäre am besten, wenn ich den Entwicklern doch eine DLL mit den Basisklassen zur Verfügung stelle, auch wenn ich dafür das Grundgerüst meines Programms umschreiben muss.

Vielen Dank für die Antwort. Sie hat mir sehr weitergeholfen

hustbaer

Wieso fällt Möglichkeit 3 weg? Das wäre die sicherste Variante, und du kannst eigentlich alles damit machen. Wenn du für die Plugins ein "schönes" C++ Interface anbieten willst lässt sich das ja relativ einfach über ein paar inline implementierte Wrapper Klassen erledigen die du mit den Header-Files mit auslieferst.

Oder bloss weil es etwas mehr Aufwand wäre?

Um was für eine Art von Projekt handelt es sich denn überhaupt?

DannyD

Die Möglichkeit ist meiner Meinung nach ungünstig, weil man für jede einzelne Methode einer Klassen einen Funktionszeiger anlegen müsste und trotzdem keinen Zugriff auf die einzelnen Klassen hat. Der Aufwand wäre aber wahrscheinlich sogar geringer.

Ein kleines Beispiel dazu: ich nutze SQLite3. Damit ein Plugin Entwickler überhaupt auf die Datenbank zugreifen kann, müsste er erst die API einbinden.

Es handelt sich bei dem Projekt um einen multiuser Server für Chat, Spiele usw.

hustbaer

Also wenn das Ding open source ist, dann wieso nicht, verwende ein C++ interface.
Wenn es closed source ist... wird es halt u.u. einfach lästig, wegen Compiler+Einstellungen müssen genau zusammenpassen.
Vor allem closed source in Kombination mit z.B. Linux machen sowas zum reinsten Horror (viel zu viele verschiedene Compiler/Library Versionen/Kombinationen).

DannyD

Es wird Closed-Source-Cross-Plattform Anwendung. In diesem Sinne ist es wohl das Schlimmste, was man überhaupt machen kann. Ich beschränke mich allerdings auf den VCPP und GCC Compiler und werde den Entwicklern einige Beispielplugins mit Sources auf den Weg geben. Wer dann einen anderen Compiler benutzt, der musst halt ein wenig probieren. Leider kann man es nicht allen Recht machen.

hustbaer

"der" GCC ist lustig, da gibts SO viele verschiedene Versionen... das kannste IMO vergessen. Auch gibt es nicht "die" glibc. Du müsstest zig Binaries für die verschiedenen Compiler Versionen bauen.

Also hier geht IMO ganz klar NUR der Weg dass du einfach ne "normale" C API machst (für die es nen halbwegs fixes ABI für die meisten Systeme ist), und diese den Clients zur Verfügung stellst. Wie gesagt, man kann ja fertige open source C++ Wrapper für diese C API mitgeben.

Und ich würde hier auch DLLs/SOs machen die den Plugins die nötigen Funktionen zur Verfügung stellen.

C++ Forumbot

Dieser Thread wurde von Moderator/in HumeSikkins aus dem Forum C++ in das Forum Rund um die Programmierung verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

rüdiger

DannyD schrieb:

jedoch bin ich darauf angewiesen innerhalb der Plugins diverse Klassen des Hauptprogramms zu verwenden.

Unter Linux/Unix gibt es für man: dlopen(2) das RTLD_GLOBAL -Flag, mit dem wäre das möglich. Vielleicht gibt es ja was ähnliches für Windos.

hustbaer

rüdiger schrieb:

DannyD schrieb:

jedoch bin ich darauf angewiesen innerhalb der Plugins diverse Klassen des Hauptprogramms zu verwenden.

Unter Linux/Unix gibt es für man: dlopen(2) das RTLD_GLOBAL -Flag, mit dem wäre das möglich. Vielleicht gibt es ja was ähnliches für Windos.

Das "Hauptprogramm" kann man doch immer so machen dass es sich auf

#include "foo.h"
int main()
{
    return Foo::Run(); // Foo::Run steckt in einer DLL/einem SO
}

beschränkt.
Dann können sämtliche Klassen auch in DLLs/SOs liegen, bzw. die entsprechende C APIs, und können genauso von Plugins verwendet werden.

sri

Wenn es nur für Windows gedacht sein soll, dann bietet sich doch COM dafür an.

DannyD

Soll auch unter Linux laufen.

hustbaer schrieb:

Das "Hauptprogramm" kann man doch immer so machen dass es sich auf
#include "foo.h"
int main()
{
    return Foo::Run(); // Foo::Run steckt in einer DLL/einem SO
}
beschränkt.

Das scheint mir die sinnvollste Variante zu sein. Das korrekte Einbetten der DLL wird dabei ein Headerfile übernehmen. Dafür würde ja auch kein Wrapper notwendig sein.

Was spricht nochmal gegen eine Skriptsprache?

DannyD

Die bisherigen Produkte für diesen Bereich basieren auf Java - also auf einer interpretierten Sprache. Die Vorgängerversion habe ich damals ebenfalls in Java geschrieben. Bei vielen Benutzern allerdings stieß die JVM jedoch an ihre Grenzen. Daher schreibe ich den Server jetzt in C++. Wenn ich nun Skriptsprachen verwende, die noch langsamer sind als interpretierte, dann hätte ich auch bei Java bleiben können

No Comment.

L.O.L. schrieb:

No Comment.

ROFL triffts eher!

Deine Befürchtungen sind im Groben und Ganzen schwachsinning.

Im übrigen hast du das falsch verstanden.

Du kannst dein Programm ja in C++ schreiben, aber bietest den Plugin-Entwicklern eine Schnitstelle, die über eine Scriptsprache realisiert ist.

DannyD

Mir ist schon klar, dass nur die Plugins gemeint waren. Aber vielleicht versteht ihr meinen Hintergrund nicht. Ich programmiere seit etlichen Jahren in verschiedensten interpretierten Sprachen und hab mir für das Projekt vorgenommen keine (bzw. keine dergleichen) zu verwenden. Was sollte also dagegen sprechen, wenn ich einfach keine Scriptsprachen verwenden möchte? Vielleicht liegen die Zeitunterschiede auch nur im Millisekundenbereich, aber meiner Meinung nach ist es genau das, worauf es beim effizienten Programmieren ankommt.

Achso: bitte argumentiert. Alles andere ist Kindergarten