Grundüberlegungen zu einem Plugin System

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

Wenn du die letzten Jahre ausschließlich mit interpretierten Sprachen gearbeitet hast, wieviel Erfahrung hast du denn mit C++?
Wenn du nicht wirklich über gute bis sehr gute C++ Kenntnisse verfügst, dann greif besser zu Java, sonst wird dein Programm eher langsamer als schneller und fehlersicherer wird es auch.

Meep Meep

hola

hustbaer schrieb:

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.

gilt das auch wenn man das interface folgend gestaltet ?

class interface
{
   public:
      void mach_was(void) { virtual_mach_was(); }

   protected:
      virtual void virtual_mach_was(void);
};

wenn man nun eine klasse davon ableitet und in eine dll gibt duerfte das ja vom kompiler und den einstellungen unabhaengig sein.

Meep Meep

Meep Meep schrieb:

hola

hustbaer schrieb:

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.

gilt das auch wenn man das interface folgend gestaltet ?
class interface
{
   public:
      void mach_was(void) { virtual_mach_was(); }

   protected:
      virtual void virtual_mach_was(void);
};
wenn man nun eine klasse davon ableitet und in eine dll gibt duerfte das ja vom kompiler und den einstellungen unabhaengig sein.

Meep Meep

Nein, das geht nicht, da C++ aus DLLs heraus zu verwenden vom Compiler abhängt das funktioniert nur mit dem gleichen Compiler, da es hierfür keinen Standard gibt.

hustbaer

@Meep Meep
Das geht auch nur dann wenn das ABI der verwendeten Compiler in dem Bereich kompatibel ist. Mit MSVC geht es z.B. soweit ich weiss mit allen Versionen ab VC6. Zumindest mit __stdcall (ohne wahrscheinlich auch). Bei GNU 3.x <-> 4.x vermute ich dass garnixmehr gehen wird (weiss ich aber nicht, müsste ich nachlesen/ausprobieren).

Was aber wirklich oft geht:

#include <c_style_foo.h> // <- lauter extern "C" sachen, keine C++ features
class foo
{
public:
    foo() { m_impl = ::new_foo(); }
    ~foo() { ::delete_foo(m_impl); }
    int bar(int x) { return ::foo_bar(m_impl, x); }
    // etc.
private:
    foo_handle m_impl;
};

Das einzige was hier noch passen muss ist dass die ABIs sich hinsichtlich normaler C Funktionen vertragen, und das geht eben recht oft.
Sonst könnte es auch keine binary Distributions für Linux Programme geben die auf jeder Linux Version laufen.

Was man natürlich auch noch beachten muss ist dass keine Exceptions fliegen dürfen, kein RTTI über DLL/SO Grenzen hinweg funktionieren wird etc.

Und new/delete nicht vergessen!

Meep Meep

noch mal damit ich das auch kapiere:

reine c-funktionen koennen verwendent werden.
klassen-member dagegen nicht. stimmt das so ?

Meep Meep

tfa

DannyD schrieb:

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

Hast du denn analysiert, warum es bei vielen Benutzern zu Problemen kam? Hier gibt es viel Optimierungsmöglichkeiten, z.B. die VM-Einstellungen (GC, Speicher etc) und die Verwendung von asynchroner I/O (java.nio.*). Am Ende programmierst du es in C++ neu, nur um dann genau die gleichen Probleme noch einmal zu haben.
Es gibt genug Beispiele von großen Client/Server-Anwendungen, die auch mit vielen Anwendern gut funktionieren.
Gerade deine Anfordernungen nach Plattformunabhängigkeit und Plugin-Fähigkeit schreien geradezu nach Java.