Grundüberlegungen zu einem Plugin System

[Ich verstehs nicht]

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

[L.O.L.]

No Comment.

[ROFL]

L.O.L. schrieb:

No Comment.

ROFL triffts eher!

Deine Befürchtungen sind im Groben und Ganzen schwachsinning.

[asasdasd]

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

[Erfahrener Troll]

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

[C++-Experte]

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.

[Du hast was vergessen]

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.