unmengen von member permutationen
-
hab ich vergessen zu sagen dass diese optimierung nicht extrem die performance zerhauen darf?
-
na schmeiss die member halt alle wech und ersetz sie durch ne get(enum/string/whatever), die die daten erst bei bedarf aus der datenbank gräbt.
-
oder ich lad sie von der diskette... klar... kommt schon, lasst die spass antworten.
-
wieso spass? wozu haben die dinger überhaupt soviele membervariablen? sieht mir eher nach unnötig aufgeblähtem konzept für ne patientientenkartei aus
-
ich hoffe du verstehst das wort 'beispiel'.
es gibt soviele member weil so ein objekt je nachdem wie es initialisiert wird (im bsp als frau/mann) dann andere eigenschaften hat, es gibt dabei unmengen von permutationen (sodass ich nicht fuer jede moeglichkeit ein dediziertes objekt schreiben kann).
-
Müssen die dynamisch änderbar sein (also kommen noch neue Member dazu, weil weitere Teile des Objektes angelegt werden? Mit templates kann man sowas schon generieren, allerdings müßte der Typ dann zur Compilezeit feststehen.
Was ist wenn Du nicht auf std::map<string,...> sondern auf std::map<int, ...> mit entsprechend definierten Konstanten gehst? Oder gar ne hash_map, da haste O(1) look-up-Zeiten und bist voll dynamisch.
-
wenn man solche permutationen hat, ist dasn ganze evtl mit der falschen relationsrichtung entwickelt worden, oder die bezogenen objekte wurden direkt integriert
evtl ist es sinnvoll auf ein anderer relationsmodell zu refactoren, um die datenmenge je klasse zu verringern und dafür mehr relationsinformationen gesondert zu speichern
-
Also ne Hash-Map mit pre-hashed Strings als Keys z.B. ist recht flott. Wenn die "Namen" gleich Integer Konstanten sind sogar noch ein kleines Stückchen schneller. SQLite mit memory DBs ist z.B. auch nicht langsam, wobei natürlich LANGE nicht so schnell wie ein direkter Zugriff auf ne Variable.
Die "Patterns" die hier weiterhelfen sind eben assoziative Container bzw. relationale Strukturen. Beides keine Ferraris, aber was anderes kenne ich nicht was sich so breit und allgemein anwenden liesse wie du die Frage formuliert hast. Optimierte Lösungen sind fast immer spezialisierte Lösungen.
Sach also einfach mal worums genau geht, vielleicht können wir uns dann besser was vorstellen und dir dann besser helfen.
-
Ich würde auch zur template-Generierung plädieren. Schau dir mal die hierarchy-generators aus der loki-lib an.
-
danke erstmal
wie ich schon sagte, geht es um klassen, die so einiges an membern haben, aber meistens werden nur wenige davon wirklich benutzt.
quasi ne klasse CWagen, die sowohl ne spoiler, tieferlegung, breitreifen, alufelgen usw. member hat, wobei nicht alle diese member in jedem wagen benutzt werden, sondern nur einige wenige z.b. braucht ein
CWagen Combi;sicherlich keine spoiler-daten
die klassen die so aufgeblaeht werden tausende male instanziert, ich denke man koennte also ENORM viel speicher sparen.
assoziative container haben aus meiner sicht irgendwie keinen vorteil gegenueber pointern die bei bedarf auf allokierte daten zeigen (da waeren sogar ne art autoptr die beim erstzugriff automatisch new aufrufen sehr praktisch typesafe und c++ style
).
was mich daran stoert ist der overhead (duerfte bei assoziativen containern eventuell noch groesser sein), da die daten manchmal nur z.b. 16byte haben und pro member dann auch ein new (overhead beim verwalten der daten bei nem new auf 16byte is auch nicht ohne).was ich zZ so als idee haette, waere ein ptr auf ein byte array in dem nur die benutzten member aneinandergereiht liegen. ob ein member im array ist, kann man sehr simpel und schnell mit einer bitmask checken, falls nicht, dann liefert die klasse den defaultwert zurueck fuer die member. bei der ersten zuweisung zu einem member, mueste das array um dieses eine member erweitert werden.
probleme die bisher ungeloest sind:
-wie generiert man am smartesten alle moeglichen indizierungen fuer die bitmask fuer alle member ohne sich den wolf zu coden? (soll ja generisch sein, da das problem hier zuhauf auftritt)
-da die member verschiedene datentypen haben und verschieden gross sind, wie indiziert man auf diese verschiedenen groessen und wie sorgt man dafuer das alles typesafe ist?werd mir jetzt die hierarchy-generators mal ansehen
