Heterogene Daten verwalten
-
class Serverdaten {}; class Serverlist : public Serverdaten { std::list<int> daten}; class Serverint : public Serverdaten {int daten}; vector<Serverdaten*> parsedString;Nur als Idee. Klar, Benennung is scheiße, blanke pointer in nem vector sind scheiße, etc etc - aber geht ja um die Idee.
-
Und wie soll dann der Zugriff geschehen?
-
Würd mal sagen, hängt davon ab was du mit den Daten machen willst. Ok, davon hängt auch ab ob diese Variante überhaupt sinnvoll is.
virtual functioncall "doSomething", sodass die Typen selbst arbeiten, wenn sie es sinnvoll können. Kannst den vektor auch sortiert machen nach relevanz der optionen, und dann mit prüfen von typeid von vorn nach hinten durchgehen.
Kannst sie auch mit hilfe der typen im vector sortieren - dafür halt ich dann aber bald ne klasse mit je einem (vector von einem...) datentyp langsam sinnvoller.
Kannst auch statt dem vector eine map<string, Serverdaten*> nehmen, wenn du den daten irgendwie namen zuordnen willst.
Also, ich hab keine Ahnung von irc und weiß deshalb nicht genau was du brauchst - deshalb sollts ja nur ne idee sein.
-
Ich habe mir gerade einen anderen Ansatz überlegt, und zwar über boost::variant. Ein Element wird als variant<int, string, ...> gespeichert, diese lege ich in einer map<name, value> ab und biete Iteratoren und evtl weitere Funktionen an. Der Benutzer kann dann einen Visitor drüberlaufen lassen und je nach Typ bestimmte Aktionen ausführen.
-
Würdest Du nicht bis zum "GenericManagerOfSomething" abstrahieren, müßtest Du auch nicht zurückcasten und Typen zur Laufzeit prüfen, befürchte ich.
-
Da hast du wohl Recht, welche Probleme gibt es denn bei meiner Lösung?
-
314159265358979 schrieb:
Da hast du wohl Recht, welche Probleme gibt es denn bei meiner Lösung?
Ich sehe keine Wand, gegen die man laufen könnte, das geht so durch.
Wird halt vielleicht ein wenig zu abstrakt für einen denkfaulen Mann wie mich.
-
Ich habe mich nun doch umentschieden. Bekannte Optionen werden in gleichnamigen Variablen gespeichert, Rest in einer map<k, v>. Die Optionen sind dabei Instanzen eines templates nullable<T>, das im Prinzip nur eine Wrapperklasse um T ist, aber eben nullptr zuweisbar ist.
Was haltet ihr davon?
-
314159265358979 schrieb:
Ich habe mich nun doch umentschieden. Bekannte Optionen werden in gleichnamigen Variablen gespeichert, Rest in einer map<k, v>. Die Optionen sind dabei Instanzen eines templates nullable<T>, das im Prinzip nur eine Wrapperklasse um T ist, aber eben nullptr zuweisbar ist.
Was haltet ihr davon?Das würde ich noch weiter treiben:
Bekannte Optionen werden in gleichnamigen Variablen gespeichert, Rest wird *nicht* gespeichert einself
Wozu was lesen und speichern, das eh nicht bekannt ist?
Und wenn Du rausgefunden hast, was die Option bedeutet, kannste ihr auch einen guten Namen und Typ geben.
-
Was hältst du von der Sache mit dem nullable? Ist das so brauchbar?
(gibts evtl in boost sowas?)
-
Ja, es gibt boost::optional.