Ich arbeite an einem Projekt, wo ich ein einfaches Plugin-System nützlich finden würde. Im Wesentlichen erstelle ich die Basisklasse und kann diese Basisklasse einem Plugin-Entwickler zur Verfügung stellen. Dann überschreibt der Entwickler es und überschreibt die Methoden. Dann wird es mir etwas unklar. Wie funktioniert es von hier? Wo finde ich Dokumentationen zur Entwicklung dieses Systemtyps?Wie funktionieren Plugin-Systeme?
Dank
Die Plugin-Systeme, die ich von allen wissen, verwenden dynamische Bibliotheken. Grundsätzlich müssen Sie einen kleinen, effektiven Handshake zwischen dem Systemkern und den Plugins definieren. Da es keine C++ - ABI gibt, müssen Plugins entweder nur eine C-API verwenden oder den gleichen Compiler (und wahrscheinlich die Compiler-Version) als Systemkern verwenden.
Das einfachste denkbare Protokoll wäre eine Funktion, die alle Plugin-Entwickler bereitstellen müssten, die eine Instanz einer von der Basisklasse abgeleiteten Klasse als Basisklassenzeiger zurückgibt. (Die extern "C" stellt sicher, dass Funktion keinen verstümmelten Namen hat, und ist somit leichter durch seine Namen zu finden.) So etwas wie:
extern "C" {
plugin_base* get_plugin();
}
Der Kernel würde dann versuchen, Binärdateien in dafür vorgesehenen Stellen als dynamisches gefunden zu laden Bibliotheken und versuchen, die get_plugin() Funktion zu finden. Wenn es erfolgreich ist, ruft es diese Funktion auf und endet mit einer geladenen Plugin-Instanz.
Natürlich wäre es schön, auch Funktionen haben, um die Version der API das Plugin gegen gegen die Version des Kernel kompiliert überprüfen wurde. (Sie könnten diese Basisklasse schließlich ändern.) Und Sie könnten andere Funktionen haben, die Informationen über das Plugin zurückgeben (oder Sie haben dies als virtuals in der Basisklasse). Das hängt sehr von der Art Ihres Systems ab.
Sie können Plugin kompilieren als dynamische/Shared Library es in Plugin-Ordner gestellt und dann aus dem Code dynamicly alle DLL-Dateien geladen werden aus dem Ordner-Plugin.
Sie können Quellcode für Programme wie GIMP überprüfen, um zu überprüfen, wie sie plugis implementieren.
Wahrscheinlich fast die einzige Dokumentation, die Sie werden in der Lage sein, bestehende Systeme zu finden sein wird.
Grundsätzlich haben Sie zwei gängige Arten von Plug-Ins. Man behandelt Dinge wie Übersetzungen zu/von einem fremden Dateityp. In diesem Fall verfügen Sie normalerweise über drei Funktionen: Eine, um das Dateiformat zu erkennen, eine, um sie zu lesen und eine, um sie zu schreiben. Zusammen mit diesen haben Sie normalerweise einige Zeichenfolgen, um eine Dateierweiterung anzugeben.
Eine andere Möglichkeit ist die Verarbeitung in Ihrem Programm. In diesem Fall werden in der Regel einige Einträge angegeben, die zu Ihrer Menüstruktur hinzugefügt werden sollen, sowie eine Funktion, die für jede aufgerufen wird. In den meisten Fällen haben Sie mindestens eine weitere Funktion, um etwas mit der Serialisierung der aktuellen Konfiguration zu tun. Von da an liegt es an Ihnen zu entscheiden, wie Sie genug von den Interna Ihres Programms bereitstellen, damit es etwas Nützliches tun kann.
Unter Linux ein Plugin ist eine gemeinsam genutzte Bibliothek (mit .so Erweiterung), die in Ihrem Plugin-API namens einer oder mehr Funktionen zur Verfügung stellt. Ihr Programm öffnet die Bibliothek mit dlopen und ruft mit dlsym Zeiger auf die Funktionen auf und ruft die Funktionen mit den Zeigern auf. Das Plugin kann jede Funktion aufrufen, die öffentlich aus Ihrem Programm exportiert wurde.
Wenn plugin_base nicht POD ist, aber es eine Klasse ist, die von der Basis-Plugin-Klasse erbt, denke ich, dass für die ganze Sache eine Art von C++ ABI (die von dem verwendeten Compiler definiert) verwendet werden müsste.: S –
@Matteo: Ja, du hast dort einen sehr gültigen Punkt. Vielen Dank. Ich habe meine Antwort entsprechend angepasst. – sbi
Kein Problem. :) BTW, eine Alternative zu Windows wäre die Verwendung von COM, die tatsächlich teilweise als C++ ABI-kompatibel mit anderen Sprachen gesehen werden kann. –