Zitat Zitat von mdi Beitrag anzeigen
Hallo,

ich habe immernoch ein Problem mir vorzustellen, was und warum genau mit dem <std::map> gearbeitet werden soll :7.

Die Sache mit den Datenobjekten finde ich da einfacher, weil (wie geschrieben) dann eine Oberklasse BASEmsg ausreicht, um egal welche Daten überall im Kern durchzuschieben ohne sich um die innere Struktur kümmern zu müssen (braucht da ja auch niemand).
Martin
Ich glaube, die abgeleiteten Klassen mit klassischen Membervariablen finde ich in sofern unflexibel, daß jedes neue Feld dann im Source-Code hinzugefügt werden muss, bevor man es verwenden kann. Eine dynamische Struktur wie die map hat hat so ein Problem nicht. Dennoch kann man die map ja in eine Klasse packen, die den Zugriff auf die Daten nochmal kapselt und überwachen kann. Hin- und herschieben kann man so eine Klasse auch ganz prima :-)

Wenn man irgendwann beschließt aus einem optionalen Backend (z.B. Datenbank) ein Feld "Fahrzeugname" in den Datensatz einzufügen wäre das möglich (Durch ein "PreDispatcher" Plugin könnten die Daten ergänzt werden.) Und das ohne, die Klassendefinition anpassen zu müssen. Gleiches gilt dann für ein vorhandenes StorageModul. Es kann die ergänzten Daten lesen und nutzen, wenn es sie abfragt. Und das alles ohne SourceCode Änderung. Und andere Module sind davon unbeeindruckt.

Da fallen mir einige Möglichkeiten ein, um den monitord an ganz verschiedene Bedürfnisse anzupassen. Ich z.B. fände es toll, wenn ein Fahrzeugname schon vor dem Weiterleiten an die Clients ergänzt wird. Oder z.B. auch der POCSAG-Text der letzten Alarmierung. Oder der vorherige Status (wenn es ein FMS Protokoll ist)...

Sagen wir also mal, daß ich denke die map ist kein Erschwernis (sofern man damit leben kann, daß alle Daten als String behandelt werden) sondern eine Option für die Zukunft :-)