Dynamischer Datenstruktur
-
David_pb schrieb:
Hä? Ich hab kein Wort verstanden von deiner Fragestellung...
nicht so schlimm... ich auch nicht
ich kanns mir nur vage vorstellen.@boris, vielleicht ist es hilfreich, wenn du uns mitteilst, was dein ziel ist?!
-
ok nochmal:
struct _A{ short X[3]; float Y[2]; struct _B{ int X[5]; } B[2]; } A;wenn man sich jetzt A im speicher liegend stack oder heap egal vorstellt (wenn short 2 byte, float 4 byte haben) 44 Bytes aneiandergereit im speicher. verstanden? wenn ich nun per OOP eine Dynamisch struktur haben wollte
class DynStrukt{ public: union { int MyInt; short MyShort; double MyDouble; }; std::vector<DynStrukt> childs; . . . . }; DynStrukt A; . . .son ungefähr könnte man dann den "struct" nachbaune.. dann ist ja das DynStrukt A objekt im speicher mit seinen Daten nicht mehr sequentiell angelegt wie bei "struct" ! Es geht um serialisierung...
-
class DynStrukt{ public: union { int MyInt; short MyShort; double MyDouble; }; std::vector<DynStrukt> childs;das sieht komisch aus. bist du sicher dass du keinen Designfe...ach lassen wir das
serialisierung geht ganz toll über die operatoren <</>>
-
ich habe trotzdem immer noch nicht dein problem verstanden. willst du jetzt diese 44 bytes in den entsprechenden containern deiner klasse haben, oder wie? falls ja, implementiere einen entsprechenden setter.
-
ja so ungefähr ich will sowa amchen wie:
DynStrukt A; BYTE buf[44]; memcpy(buf,A.rawdata());die methode "rawdata()" soll dann das objekt als bytesequenz zurückgeebn...
P.S.: Kann sein das Designfehler drin waren hab das mal schnell hier hin gedüdelt
-
Dann schreibe eine Funktion rawdata(), die den Bytestrom als Array von unsigned char erstellt und kopier die Werte einzeln rein. Dabei kannst Du auch gleich (viel besser als bei structs) dafür sorgen dass Formate und Endianness stimmen.
-
cool.. und wie kann ich es machen, damit das ganze TYPEN unabhängig ist.. wie ich oben mit "union" beschreiben wollte?
-
solange buf ein char array bleibt ist das auch kein problem. sobald buf aber auf eine struktur zeigt würde ich dringend von memcpy() abraten ;). übergebe lieber einen zeiger oder eine referenz der struktur an eine methode, und fülle sie dann entprechend
-
wieso ist von memcpy abzuraten, von dem abgesehen das dies C ist?
-
Weil du z.B. Zeigerwerte auch einfach mitkopierst. Und die sind unter garantie beim wiedereinlesen nicht mehr korrekt.
Für POD Typen funktioniert memcpy aber. Du kannst dir dazu übrigens auch das Parameterized Base Class Idiom ansehen.
-
abhängig vom umfang der struktur kann dir das alignment sehr viel kopfzerbrechen bereiten, insbesondere wenn du code portierst und mit fließpunktzahltypen arbeitest.
-
BorisDieKlinge schrieb:
cool.. und wie kann ich es machen, damit das ganze TYPEN unabhängig ist.. wie ich oben mit "union" beschreiben wollte?
Wie würdest Du das denn mit der "union" machen?
Richtig: Du musst Dir irgendwie merken, welcher Typ gerade gültig ist.
-
stimmt , ich müsste mir den tp zusätzlich merken.. so machen es ja die MFC COleVariant typen glaub auch
-
BorisDieKlinge schrieb:
P.S.: Kann sein das Designfehler drin waren hab das mal schnell hier hin gedüdelt
Der Designfehler besteht darin, irgend eine Struktur via wildes memcpy kopieren zu wollen. Padding, Aligment und Byte-Order sind ein Problem, hinzukommt der Unterschied von 32Bit- und 64Bit-Laufzeitumgebung.
Für das Kopieren von Klassen ist der Kopierkonstruktor bzw. der Kopierzuweisungsoperator zuständig, und für das Serialisieren verwendet man spezielle Funktionen, die den Speicherinhalt in ein möglichst plattformneutrales Format umwandelt.