Ich bin momentan dabei meinen IRC-Bot von Ruby in C++ neu (um)zu( )schreiben. Der Kern war relativ schnell fertig, und nun bin ich beim Plug-in System angelangt.

In Ruby war das natürlich sehr einfach, da es eine Interpretersprache ist (Dateien werden dynamisch geladen, eine in jedem Plug-in vorhandene, immer gleichnamige "Anmelde"-Funktion wird aufgerufen, welche eine Funktion im "Eventhandler" Registriert und das Bot-Objekt übergeben wird. Sobald neue Daten empfangen werden, werden diese registrierten Funktionen aufgerufen und die Daten als Argument übergeben. Im Plug-in kann dann alles mögliche passieren, und dank Zugriff auf das Bot-Objekt ausgegeben werden.).

Das wird aber leider nicht auf C++ übertragbar sein. Daher meine Frage in der Hoffnung auf ein paar Ideen: Wie kann ich ein ähnliches System in C++ übertragen? Die Plug-ins sollten so individuell wie möglich gestaltbar sein. Das einzige auf was die Plug-ins zugreifen müssen bzw. zur verfügung gestellt bekommen müssen, sind die empfangenen Daten. Und einen Weg eventuelle "Ergebnisse" ausgeben zu können.

Wie ist sowas realisierbar? Über DLLs?

Ich bin momentan dabei meinen IRC-Bot von Ruby in C++ neu (um)zu( )schreiben.

Warum sollte man so etwas tun?

hunto schrieb:

Ich bin momentan dabei meinen IRC-Bot von Ruby in C++ neu (um)zu( )schreiben.

Warum sollte man so etwas tun?

Schneller mehr Spam?

hunto schrieb:

Ich bin momentan dabei meinen IRC-Bot von Ruby in C++ neu (um)zu( )schreiben.

Warum sollte man so etwas tun?

Im Grunde erstmal als Übung. Und es ist eine gute Übung für gesuchtes Plug-in System, welches ich dann auch in anderen Projekten verwenden kann.

Keine Ideen?

1. Man nutzt dynamische Libs (z.B. DLLs), die ein bestimmtes Interface implementieren müssen. Dieses Interface dient als "Kommunikation", zwischen Programm und Plugin. Mit Kommunikation ist aber nicht unbedingt Nachrichten gemeint, sondern es können einfach Funktions- und Methoden-Aufrufe sein, wo wichtige Daten übergeben und abgefragt werden können. Das kann alles in C oder C++ implementiert werden.

2. Man nutzt eine Script-Engine: http://www.kharchi.eu/wiki/doku.php?id=cpp:scripting#scriptsprachen
Hier werden die Plugins aber nicht in C++ implementiert. Aber für kleine Systeme/Aufgaben sicherlich ausreichend.

3. Man nutzt CORBA. Mit Kanonen auf Spatzen geschossen, aber dafür kann man das Plugin sogar auf einem fremden Rechner laufen lassen.

4. Man nutzt IPC http://www.boost.org/doc/libs/1_40_0/doc/html/interprocess.html und erstellt die Plugins als ausführbare Programme (z.B. EXE unter Windows).

5. Wenn man sich auf Windows beschränken will, kann man ActiveX benutzt. ActiveX ist DAS Plugin-System unter Windows! Die ATL kann einem dabei das Leben beim Erstellen von ActiveX-Komponenten unheimlich erleichtern.

So... aber am Ende zählt bei ALLEN Konzepten: die Plugins müssen sich an ein Interface halten.

4. Man nutzt http://www.boost.org/doc/libs/1_40_0/doc/html/mpi.html und erstellt die Plugins als ausführbare Programme (z.B. EXE unter Windows).

Hast Du MPI für solche Zwecke schonmal benutzt? Ich glaube nämlich, dass das gar nicht so läuft. Ich dachte, MPI started dasselbe Programm mehrfach, welches dann über die API erfragen kann, welche "Knoten-ID" der Instanz zugeordnet worden ist und wieviele Knoten es gibt.

Artchi schrieb:

4. Man nutzt http://www.boost.org/doc/libs/1_40_0/doc/html/mpi.html und erstellt die Plugins als ausführbare Programme (z.B. EXE unter Windows).

Hast Du MPI für solche Zwecke schonmal benutzt? Ich glaube nämlich, dass das gar nicht so läuft. Ich dachte, MPI started dasselbe Programm mehrfach, welches dann über die API erfragen kann, welche "Knoten-ID" der Instanz zugeordnet worden ist und wieviele Knoten es gibt.

Sorry, hab MPI falsch rausgesucht! Meinte IPC.

zu 1.): Wie weiß das System, welche DLL's sie beim starten laden muss? Unter Windows gibts da eine Möglichkeit, aber das ganze sollte ja auf allen System funktionieren.

Wie weiß das System, welche DLL's sie beim starten laden muss?

Zum Beispiel durch eine Konfigurationsdatei, in der die zu ladenden DLLs aufgelistet werden.
Oder man gibt ein Verzeichnis vor, in dem die Plugin-Dateien abgelegt werden müssen und der Pluginmanager lädt alle DLLs, die er dort findet.