ich wollte mich mal etwas mit boost beschäftigen und habe somit eine IRC-Lib angefangen, welche auf Boost.Asio zurückgreift.
Um einen EventManager zu realisieren, wollte ich eine Event-Klasse schreiben, welche jeweils einen Namen und beliebig viele, indexierte (std::vector) Argumente hat, welche natürlich jeweils verschiedene Typen aufweisen können (z. B. Channel, User, Mode, std::string, int, ...).
Da dachte ich dann an Boost.Any. Natürlich ist auch Boost.Any kein Wunderwerk und erstellt intern natürlich Kopien, was für meine Belange gar nicht so gut ist... oder denke ich falsch? Und mit Pointern wollte ich eigentlich nicht umwerfen.

Hier ist die Event-Klasse: http://42.holz.nu/6e793.png

Ist das schlechtes Design?
Wie würdet ihr das machen?

Vielen Dank!

log<<"User "<<ev.params[7].get<User>().name()<<" hat den Channel "<<ev.params[3].get<Channel>().name()<< "betreten.\n";

Weil ich Custom-Events erlauben will.
Die Library soll durch Module erweiterbar sein, d. h. Modul 1 soll bspw. das Event "Bla" feuern können, und alle anderen sollten es empfangen können.
Das geht mit vordefinierten Klassen nicht so gut / gar nicht.

Können alle anderen die Events denn überhaupt verarbeiten?
Würde es reichen, eine gemeinsame Basisklasse zu haben?

Wenns denn unbedingt sein muß, würde ich an variadic templates denken.

Wie soll das mit Templates funktionieren? Und auch, wie das aus deinem ersten Post (das, was du reineditierst hast) funktionieren soll, verstehe ich nicht? Dann würden ja jedes mal Kopien eines Users erstellt werden.

VS2012 kann leider keine Variadic Templates.
Ja, können sie.
Beispielsweise kennt das IRC von Haus aus kein UserAuthed-Event. Für das Quakenet würde ich dann ein Module schreiben, welche das feuert, damit andere das benutzen können.

Ja, und wer ein UserAuthed-Event benutzen will, muss aber schon die selbe "UserAuthedEvent.hpp" inkludieren. Und alle Events erben von Event.
Kann mir nicht vorstellen, daß irgend ein Event-Empfänger (außer dem Logger) ein Event empfangen möchte und verarbeiten kann, von dem er nicht vorher die Struktur kennt.

registerEventHaqndler("UserAuthedEvent",this);
...
void processEvent(Event* e){
   UserAuthedEvent uae=static_cast<UserAuthedEvent*>(e);//dynamic_cas ist völlig überbewertet, löl. 
   //tuwas
}

Passen die signals von boost?

class Bla
{
public:
    void OnUserAuthed(UserAuthedEvent *e)
    {
    }
};

// ...

Bla b;
EventManager x;

x.RegisterListener("UserAuthed", boost::bind(&Bla::OnUserAuthed, &b, _1));

Würde so etwas gehen? Wenn ja, wie muss die Signatur von EventManager::RegisterListener() aussehen?
Vielen Dank

wie muss die Signatur von EventManager::RegisterListener() aussehen?
Vielen Dank

Wenn der Aufruf steht, kannste den Compiler fragen. Einfach eine Funnktion mit falscher Signatur anbieten und compilieren und die richtige Signatur in der Fehlermeldung lesen.

Dabei musst du natürlich Typsicherheit garantieren, sonst wird das mit dem Downcast nichts.

Falls ja, das exakt selbe Problem habe ich gelöst, indem ich die Nachrichten als XML-Text verschickt habe.

Jeder kann sich als Nachrichten-Empfänger anhängen (via boost::signals). Wer was mit der Nachricht anfangen kann, bearbeitet sie, und schickt die Antwort ebenfalls per XML.

Wenn ich dich richtig verstanden habe, ist das Problem, dass du zur Compilezeit noch nicht weisst, welche Nachrichten kommen, und du in Zukunft ohne das das Hauptprogramm neu compiliert wird weitere Nachrichten hinzukommen?

Falls ja, das exakt selbe Problem habe ich gelöst, indem ich die Nachrichten als XML-Text verschickt habe.

Jeder kann sich als Nachrichten-Empfänger anhängen (via boost::signals). Wer was mit der Nachricht anfangen kann, bearbeitet sie, und schickt die Antwort ebenfalls per XML.

Optimalerweise gibt es für die Nachrichten auch Dokumenttypdefinitionen. Außer bei so platten Sachen wie "Anzeigen der Nachricht" braucht der Empfänger ja eine Wissen darüber, was er zu erwarten hat.
Also teilen sich Sender und Empfänger eine DTD zu dieser XML-Nachricht. Das Kernsystem muß davon überhaupt keine Ahnung haben, nicht die Geringte. Es sieht nur XML, ohne reinzugucken. Es können zwei Plugins trotzdem Nachrichten austauschen, sie sind sich eben zur Compilezeit über das Format einig.

Na, mal hoffen, daß das nicht nach inner platform effect riecht.

Headerfile statt DTD und Basisklassenzeiger statt XML und man hats als Sprachmittel. Ich verstehe Eure Motivation nicht. Odert redest Du gerade bloß davon, Nachrichten zu serialisieren, damit man sie übers Netz schicken kann?

Okay, dynamic_cast verlangt natürlich nach einem kompatiblen Compiler... Dann halt eine normale struct mit GUID-Message Ids und reinterpret_cast...

static_cast

Danke schonmal für Aufklärung.

Edit: Hrmmm, mehrfach-Vererbung vielleicht? Die konkrete Nachricht leitet von der Basisnachricht und etwas anderem ab, eventuell in anderer Reihenfolge, sodass die Basisnachricht nicht "vorne" im Speicher liegt?
Edit2: Herrje, wie funktioniert in solch einem Fall eigentlich das delete? Okay, die Zerstörung geht dank virtuellem Destruktor ja problemlos, aber wie bekommt delete die Richtige Basisadresse raus? Gibt's da eine versteckte virtuelle Funktion, die die Basisadresse der konkreten Klasse ausspuckt?

Macht es denn bei so einer Form von Downcast einen Unterschied, ob ich reinterpret_cast oder static_cast verwende?

Ich weiß jetzt nicht genau, was für einen Cast du meinst. Aber wenn du dich innerhalb einer Vererbungshierarchie bewegst, solltest du entweder dynamic_cast oder static_cast verwenden. Bei reinterpret_cast findet ein ggf notwendiges Adjustment nicht statt. Das knallt dir dann spätestens bei Mehrfachvererbung um die Ohren, siehe hier.

#include <iostream>

using namespace std;

struct A {int i;};
struct B {int j;};
struct C : A, B {};

int main()
{
  C c;
  B& b = c;
  C& c2 = static_cast<C&>(b);
  C& c3 = reinterpret_cast<C&>(b);
  cout << &c << endl;
  cout << &b << endl;
  cout << &c2 << endl;
  cout << &c3 << endl;
}

Bei meinem Test sieht man, dass die Adressen &c und &b unterschiedlich sind. Der static_cast für c2 ist quasi die Umkehrung dieser impliziten Wandlung und stellt die richtige Adresse wieder her. Der reinterpret_cast führt hier dazu, dass c3 keine gültige Referenz auf ein C-Objekt ist.

Hast Du auch eine Ahnung wie das mit dem Löschen bei Mehrfachvererbung läuft, wie ich im zweiten Edit fragte?

Edit2: Herrje, wie funktioniert in solch einem Fall eigentlich das delete? Okay, die Zerstörung geht dank virtuellem Destruktor ja problemlos, aber wie bekommt delete die Richtige Basisadresse raus? Gibt's da eine versteckte virtuelle Funktion, die die Basisadresse der konkreten Klasse ausspuckt?

Naja, dass es für die Implementierung kein Problem sein kann/darf, die "Basisadresse" zu ermitteln, sollte ja wohl klar sein.

Der VTable-Zeiger eines z.B. Foo-Teilobjekts das Teil eines Bars ist zeigt (bei Mehrfachverrebung) ja nicht auf den Foo-VTable oder Bar-VTable, sondern auf einen speziellen Foo-in-Bar-VTable.
Da der VTable nicht nur die Adressen von virtuellen Funktionen enthält, sondern auch einen Zeiger auf Informationen über das Layout des konkreten Objekts, kann man da einiges machen.
Ist auch nötig, sonst könnte dynamic_cast nicht implementiert werden.

Und um deine konkrete Frage auch noch zu beantworten: ja, es gibt so eine Funktion, und zwar dynamic_cast<void*>(p) (wobei das nicht unbedingt eine versteckte virtuelle Funktion ist, aber es werden sicher Informationen aus dem VTable oder darin verlinkten Datenstrukturen verwendet). Das liefert die Adresse des "most derived object" -- also die Anfangsadresse des konkreten Objekts.
Das wird auch die Adresse sein die üblicherweise an operator delete übergeben wird. Bzw. ich meine sogar dass es immer die Adresse sein muss die an operator delete übergeben wird, ich glaube nicht dass der Standard hier genug Spielraum lässt es anders zu implementieren.