Der sizeof Operator liefert falsche Grösse?
-
Wozu benötigst du denn die Größe? Normalerweise benötigt man die Größe nicht.
-
Sobald es übers Netzwerk etc. geht, brauchst du die Größe um zu sehen ob alle Daten da sind.
-
Fellhuhn schrieb:
Sobald es übers Netzwerk etc. geht, brauchst du die Größe um zu sehen ob alle Daten da sind.
Und genau da macht man was falsch. Man darf niemals direkt in eine Struktur lesen oder aus dieser schreiben. Auch darf man nicht anhand der Struktur-Größe prüfen ob alle Daten angekommen sind.
-
Ojeoje I see, I see...
Fragt sich, wieso sie beim 3ds Format ein 6Byte Header verwendet haben? Ist das Format so alt, dass es noch aus der 16Bit Ära stammt? Dort hätte es natürlich kein Padding gemacht für 6Bytes...
-
// obtain the assigned resource reader and open the data source ResourceReader *pRdr = this->GetReader(); pRdr->Open(); // allocate memory and load the entire data into memory uint32 szSrc = pRdr->Size(); uint8 *pDta = new uint8[szSrc]; uint8 *pEnd = pDta + szSrc; pRdr->Read(pDta,0,szSrc);Weil ich folgenden Code schöner finde
// throw an exception if the signature inside the *.3ds file is invalid DsTokenHeader *pHdr = reinterpret_cast<DsTokenHeader*>(pDta); if(pHdr->ID != 0x4d4d) throw DecoderException(FNC,stHdr); if(pHdr->Size != szSrc) throw DecoderException(FNC,stHdr); pDta += sizeof(DsTokenHeader);als diesen hier (leider funktioniert "dank" dem Padding nur dieser hier...)
// throw an exception if the signature inside the *.3ds file is invalid if(*reinterpret_cast<uint16*>(pDta) != 0x4d4d) throw DecoderException(FNC,stHdr); if(*reinterpret_cast<uint32*>(pDta+2) != szSrc) throw DecoderException(FNC,stHdr); pDta += 6;
-
Warum sollte man dort unbedingt ein Padding machen? Ist letztendlich im Dateiformat egal. Du liest 6 byte und hast deinen Header. Du musst nur eben die Werte einzeln in deine Struktur kopieren.
-
Ishildur schrieb:
Ojeoje I see, I see...
Fragt sich, wieso sie beim 3ds Format ein 6Byte Header verwendet haben? Ist das Format so alt, dass es noch aus der 16Bit Ära stammt? Dort hätte es natürlich kein Padding gemacht für 6Bytes...also sollte man immer dafür sorgen, dass eigene structs mind. 64bit groß ist, wenn man modern erscheinen möchte? Oo
wie schon gesagt wurde, ist dein weg nicht gerade hübsch und die größe völlig belanglos...bb
-
Gerade der zweite sollte nicht funktionieren!!
Denn da gibst du ja von Hand an, bei welchem Byte dein Integer startet (pDta+2). Also machst du schon vorher irgendwo etwas falsch.
-
Ishildur schrieb:
Weil ich folgenden Code schöner finde
// throw an exception if the signature inside the *.3ds file is invalid DsTokenHeader *pHdr = reinterpret_cast<DsTokenHeader*>(pDta); if(pHdr->ID != 0x4d4d) throw DecoderException(FNC,stHdr); if(pHdr->Size != szSrc) throw DecoderException(FNC,stHdr); pDta += sizeof(DsTokenHeader);Ist vielleicht schöner, hat aber leider ein undefiniertes Resultat. Du gehst hier von einem bestimmten Struktur-Layout aus, das vom Standard nicht garantiert wird und Sache des Compilers ist.
-
ist dein weg nicht gerade hübsch und die größe völlig belanglos...Ok, wie mache ich es hübscher?

-
Ishildur schrieb:
ist dein weg nicht gerade hübsch und die größe völlig belanglos...Ok, wie mache ich es hübscher?

Struktur erstellen. 2 Byte in ID laden, 4 byte in Size laden. Nicht 6 byte direkt in die Struktur laden.
-
@Janjan
Doch genau das zweite funktioniert eben, weil ich dort keine Strukturen verwende, die gepadded werden. Und der pDta Pointer enthält einen Zeiger auf eine Speicheradresse, wo ich vorher das komplette File hineinlese. Und im 3ds File format ist nunmal ein Header: 2 Bytes für die ID und 4 Bytes für die Grösse.
-
@Janjan
So?DsTokenHeader hdr; memcpy(&hdr,pDta,2); memcpy(&hdr.Size,pDta+2,4); // throw an exception if the signature inside the *.3ds file is invalid if(hdr.ID != 0x4d4d) throw DecoderException(FNC,stHdr); if(hdr.Size != szSrc) throw DecoderException(FNC,stHdr); pDta += 6;Bleibt vielleicht noch zu erwähnen, dass ich das ziemlich oft an ziemlich vielen verschiedenen Stellen machen muss...
-
Du programmierst C++, kein C. Also lass das memcpy weg.
hdr.ID = *reinterpret_cast<uint16*>(pDta); hdr.Size = *reinterpret_cast<uint32*>(pDta+2);
-
Aha:
// first copy the header onto the stack (which is an unnecessary and useless overhead by the way, but ok, we are programming C++ ;-) DsTokenHeader hdr; hdr.ID = *reinterpret_cast<uint16*>(pDta); hdr.Size = *reinterpret_cast<uint32*>(pDta+2); // throw an exception if the signature inside the *.3ds file is invalid if(hdr.ID != 0x4d4d) throw DecoderException(FNC,stHdr); if(hdr.Size != szSrc) throw DecoderException(FNC,stHdr); pDta += 6;anstatt:
// throw an exception if the signature inside the *.3ds file is invalid if(*reinterpret_cast<uint16*>(pDta) != 0x4d4d) throw DecoderException(FNC,stHdr); if(*reinterpret_cast<uint32*>(pDta+2) != szSrc) throw DecoderException(FNC,stHdr); pDta += 6;Sag mal, kann es sein, dass du pro Codezeile bezahlt wirst? :p
-
Code 1 hast du die Daten bereits in deiner Struktur und kannst die Struktur weiterverwenden.
Code 2 müsstest du die Daten im nachhinein nochmal in die Struktur kopieren um sie zu verwenden.
-
@Janjan
Hehe nein ist schon klar
Es ist hier ein wenig speziell, da ich die Daten nur ein einziges Mal benötige, da ich ja jedes Token nur ein einziges Mal auslese. Aber du hast natürlich recht, wenn ich die Daten mehrmals benötige, würde ich es auch so machen wie du. Es ist halt reine Faulheit, dass ich gerne ganze Strukturen kopiere, anstatt da jedes Element einzeln, aber dann muss man halt höllisch aufpassen, dass bei den verwendeten Strukturen kein Padding auftritt. Im Zusammenhang mit der Umstellung auf 64bit werden wohl allerdings so einige Dateiimporter nicht mehr funktionieren. Bspw.struct PcmHeader{ int8 RiffSig[4]; int32 WaveformChunkSize; int8 WaveSig[4]; int8 FormaSig[4]; int32 FormatChunkSize; int16 FormatTag; int16 Channels; int32 SampleRate; int32 BytesPerSec; int16 BlockAlign; int16 BitsPerSample; int8 DataSig[4]; int32 DataSize; };Diese Struktur ist 32-bit alignet, es findet IMHO nirgends ein Padding statt. Daher funktioniert ein memcpy problemlos. Bei der Umstellung auf 64bit geht dann leider gar nichts mehr, da heissts dann Member by Member...
-
Möglicherweise irre ich mich, aber ich glaube zu wissen dass dieser Speicherzugriff nach
reinterpret_castvom Standard nicht erlaubt wird. Der Hintergrund ist, dass Speicherzugriffe je nach Architektur nur an korrekt ausgerichteten Adressen ausgeführt werden können. Ein gelesener 32-Bit-Wert muss z. B. an einer 32-Bit-Adresse ausgerichtet sein. Das ist hier nicht garantiert.Falls ich mich irre, werde ich sicher bald korrigiert.
-
Ishildur schrieb:
Diese Struktur ist 32-bit alignet, es findet IMHO nirgends ein Padding statt. Daher funktioniert ein memcpy problemlos.
Zufall. Die Reihenfolge der einzelnen Felder im Speicher ist nicht definiert.
-
Ishildur schrieb:
@Janjan
Hehe nein ist schon klar
Es ist hier ein wenig speziell, da ich die Daten nur ein einziges Mal benötige, da ich ja jedes Token nur ein einziges Mal auslese. Aber du hast natürlich recht, wenn ich die Daten mehrmals benötige, würde ich es auch so machen wie du. Es ist halt reine Faulheit, dass ich gerne ganze Strukturen kopiere, anstatt da jedes Element einzeln, aber dann muss man halt höllisch aufpassen, dass bei den verwendeten Strukturen kein Padding auftritt. Im Zusammenhang mit der Umstellung auf 64bit werden wohl allerdings so einige Dateiimporter nicht mehr funktionieren. Bspw....Diese Struktur ist 32-bit alignet, es findet IMHO nirgends ein Padding statt. Daher funktioniert ein memcpy problemlos. Bei der Umstellung auf 64bit geht dann leider gar nichts mehr, da heissts dann Member by Member...
Code der schlecht programmiert wurde wird nicht mehr funktionieren, da hast du recht.
Wer guten Code produzieren will, der weiß das man nicht direkt aus Strukturen lesen und in Strukturen schreiben darf, genau wegen der Padding Geschichte.
Der Standard schreibt eben nicht vor, dass alle Elemente zusammenhängend im Speicher stehen.