Implementieren eines Plugin-Systems in C oder C++ [closed]

Was sind Ihre Tipps zur Implementierung eines Plugin-Style-Systems?

In C (und ich denke auch C++, obwohl ich es selbst noch nicht gemacht habe) geschieht dies meistens mit dynamisch geladenen Modulen. Die APIs dafür sind plattformabhängig.

Unter POSIX (Linux) verwenden Sie die dlopen() Familie von Funktionen. Grundsätzlich erstellen Sie Ihr Plugin separat, laden es dann zur Laufzeit, suchen seine Symbole nach Namen und können sie dann aufrufen.

Für Win32 gibt es LoadLibrary() was etwas sehr ähnliches tut, bauen Sie Ihren Code in eine DLL ein.

Einen praktischen Wrapper, der all dies einfach und transparent macht, finden Sie in GLibs GModul API.

Im Zeitrahmen ’92/’93 arbeitete ich an einer Plugin-Architektur für Aldus PageMaker, die in C++ codiert war. PageMaker wurde auf einem C++ OOP-Framework namens VAMP aufgebaut, das seine Portabilität zwischen Mac OS und Windows unterstützte.

Also haben wir versucht, die Features von C++ zu nutzen, um eine Plugin-Architektur zu bauen. Dies erwies sich für C++-Klassen aufgrund des sogenannten Problems der spröden Basisklasse als sehr problematisch. Ich fuhr fort, einen Aufsatz zu schreiben, der in Zeitschriften veröffentlicht wurde und den ich auf der OOPSLA ’93 in einem Reflexionsworkshop vorstellte. Ich nahm auch Kontakt mit Bjarne Stroustrup auf einer Usenix-Konferenz in Portland auf und führte mehrere Monate lang Gespräche mit ihm, wo er sich in meinem Namen für die Lösung des Problems der spröden Basisklasse einsetzte. (Leider wurden damals andere Themen als wichtiger erachtet.)

Microsoft führte das COM/DCOM-System ein und für diese Plattform wurde es als praktikable Lösung für das Problem angesehen. C++ könnte als Implementierungssprache für COM über abstrakte Klassen verwendet werden, die zum Definieren von COM-Schnittstellen verwendet werden.

Heutzutage meiden Entwickler jedoch COM/DCOM.

Im Gegensatz dazu entwickelte NeXT Anfang der 90er Jahre eine Plugin-Architektur mit Objective C im NeXT Step-Framework. Heute lebt das lebendig in Mac OS X auf Apples Computern und wichtigen Plattformen wie dem iPhone weiter.

Ich schlage vor, dass Objective C aktiviert ist, um das Plugin-Problem auf überlegene Weise zu lösen.

Ich persönlich betrachte das spröde Basisklassenproblem von C++ als den schwerwiegendsten Fehler.

Wenn Sie eine Plugin-Architektur mit der C-basierten Sprachfamilie erstellen würden, würden Sie dies mit Objective C tun.

Der beste plattform- und sprachneutrale Rat, den ich geben kann, ist dieser:

Entwerfen Sie Ihre gesamte App rund um das Plugin-SDK.

Meiner Meinung nach sollte ein Plugin-SDK kein nachträglicher Einfall sein. Wenn Sie Ihre App so gestalten, dass sie im Grunde eine leere Hülle ist, die Plugins lädt, dann werden die Kernfunktionen in Ihrem eigenen SDK implementiert, Sie erhalten die folgenden Vorteile:

• Hohe Modularität der Komponenten und klare Trennung des Zwecks (es zwingt Ihre Architektur irgendwie dazu, gut zu sein)
• Es zwingt Ihr SDK, wirklich gut zu sein
• Es ermöglicht anderen Drittentwicklern, ebenfalls extrem leistungsstarke Funktionen auf Kernebene zu erstellen
• Neue Entwickler/Mitarbeiter können ganz einfach mit der Arbeit an einer wichtigen neuen Funktion beginnen, ohne die Haupt-App berühren zu müssen – sie können ihre gesamte Arbeit in einem Plugin erledigen (was verhindert, dass sie etwas anderes vermasseln).

In C/C++ verwenden Sie wahrscheinlich Dynamic Link Libraries und entweder Funktionszeiger (C) oder Schnittstellen (Klassen, die ausschließlich aus rein virtuellen Methoden bestehen, für C++). Aber selbst wenn Sie Javascript verwenden, würde ich trotzdem die obige Architektur empfehlen.

Qt bietet QPluginLoader:
http://qt-project.org/doc/qt-4.8/qpluginloader.html

Wenn Sie eine feinkörnigere Steuerung benötigen/wollen, bietet Qt mit QLibrary auch eine Möglichkeit, Bibliotheken im Handumdrehen zu laden:
http://qt-project.org/doc/qt-4.8/qlibrary.html

Noch besser, diese sind plattformübergreifend portierbar.

Dies ist möglicherweise nicht das, wonach Sie suchen, aber Sie könnten eine Skriptsprache wie Lua in Ihre Anwendung einbetten. Lua wurde entwickelt, um in andere Programme eingebettet zu werden und als Skriptsprache zum Schreiben von Plugins verwendet zu werden. Ich glaube, es ist ziemlich einfach, den Lua-Interpreter zu Ihrem Programm hinzuzufügen, obwohl ich Lua nicht kenne, also kann ich nicht dafür bürgen, wie effektiv eine Lösung wäre. Andere mit mehr Erfahrung mit Lua, fügen Sie bitte Kommentare zu Ihrer Erfahrung mit der Einbettung von Lua in eine andere Anwendung hinzu.

Dies würde natürlich bedeuten, dass Ihre Plugins in Lua geschrieben sein müssen. Wenn du Lua nicht magst, dann die de facto Standardperl-, Python- und Ruby-Interpreter sind alle in C geschrieben und können in ein C-Programm eingebettet werden. Ich kenne eine Reihe von Programmen, die diese Sprachen als Skriptsprachenerweiterungen verwenden.

Ich weiß jedoch nicht, wonach Sie suchen, da Ihre Frage etwas vage ist. Vielleicht wären mehr Informationen darüber, was die Leute mit diesen Plugins machen sollen, angebracht. Für einige Aufgaben kann eine ausgewachsene Skriptsprache etwas übertrieben sein.

Ich habe einen Artikel darüber geschrieben, wie man ein Plugin-System mit Dynamic Linking Libraries implementiert. Der Artikel ist aus der Sicht eines Windows-Programmierers geschrieben, aber die Technik kann auf eine Umgebung vom Typ Linux/Unix angewendet werden.

Den Artikel finden Sie hier: http://3dgep.com/?p=1759

Der wichtigste Punkt ist, dass Sie eine “gemeinsame” DLL erstellen sollten, die sowohl von der Hauptanwendung (der Kernanwendung) als auch von den Plugin-Implementierungen implizit verknüpft wird. Die Plugins können dann explizit verlinkt und dynamisch zur Laufzeit von der Kernanwendung geladen werden.

Der Artikel zeigt auch, wie Sie eine statische (Singleton-)Instanz einer Klasse sicher über mehrere DLLs hinweg freigeben können, indem Sie die “gemeinsame” DLL verwenden.

Der Artikel zeigt auch, wie Sie eine „C“-Funktion oder Variablen aus einer DLL exportieren und die exportierten Funktionen in der Anwendung zur Laufzeit verwenden können.

Verwenden Sie am besten ein Framework wie ACE (http://www.cs.wustl.edu/~schmidt/ACE.html), das Sie (so gut wie möglich) vor plattformspezifischer Codierung schützt.

ACE enthält ein Plugin-Framework, das auf gemeinsam genutzten Bibliotheken basiert, mit denen Sie dynamisch zusammengestellte Anwendungen erstellen können.

Für eine Abstraktion auf höherer Ebene schau dir CIAO (http://www.cs.wustl.edu/~schmidt/CIAO.html) die Open-Source-C++-Implementierung des CORBA-Komponentenmodells.