3. Der sizeof Operator liefert falsche Grösse?

Der sizeof Operator liefert falsche Grösse?

  • R

    Möglicherweise irre ich mich, aber ich glaube zu wissen dass dieser Speicherzugriff nach reinterpret_cast vom 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.

    0
  • R

    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.

    0
  • ?

    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.

    0
  • I

    @Registrierter Troll
    Du machst mir Angst...
    Auf deine Aussage habe ich leider keine Antwort, ich bin immer davon ausgegangen, dass jedes Byte im Speicher adressiert werden kann. Unabhängig von der Architektur. Bei 32bit kann ich ja IMHO ca. 4GB speicher addressieren. Eine Konsequenz deiner Aussage währe ja doch dann, dass ich ca. 16BG adressieren könnte, aber halt nur jedes 4te Byte?

    0
  • I

    @Janjan
    Viele Tutorials und Bücher, die ich gelesen habe und die Verarbeitung von Binärdaten behandeln, lesen und schreiben direkt in und aus Strukturen aus oder in Dateien...

    Daher bin ich ehrlich gesagt gerade ein wenig schockiert... 😮

    0
  • ?

    Ishildur schrieb:

    @Registrierter Troll
    Du machst mir Angst...
    Auf deine Aussage habe ich leider keine Antwort, ich bin immer davon ausgegangen, dass jedes Byte im Speicher adressiert werden kann. Unabhängig von der Architektur. Bei 32bit kann ich ja IMHO ca. 4GB speicher addressieren. Eine Konsequenz deiner Aussage währe ja doch dann, dass ich ca. 16BG adressieren könnte, aber halt nur jedes 4te Byte?

    Das ist unsinn. Mag sein, dass eine Architektur nur an jedem 4ten Byte zugreifen kann, aber die Implementierung deines C++ Codes muss dies berücksichtigen. Dann muss eben der geschriebene Maschinencode zur Not 3 byte früher lesen, und die ersten 3 Byte wegwerfen. Darauf musst du dank Standard in deinem Code nicht achten, darauf muss der Compiler für dich achten. 😉

    0
  • ?

    Ishildur schrieb:

    @Janjan
    Viele Tutorials und Bücher, die ich gelesen habe und die Verarbeitung von Binärdaten behandeln, lesen und schreiben direkt in und aus Strukturen aus oder in Dateien...

    Daher bin ich ehrlich gesagt gerade ein wenig schockiert... 😮

    Die machen es schlichtweg falsch. Es gibt leider sehr sehr sehr viele schlechte Tutorials und Bücher...

    0
  • I

    @Janjan
    Puuhhhh.... Dank dir kann ich wieder ruhig schlafen 😃

    0
  • R

    Ishildur schrieb:

    Auf deine Aussage habe ich leider keine Antwort, ich bin immer davon ausgegangen, dass jedes Byte im Speicher adressiert werden kann. Unabhängig von der Architektur.

    Kann es ja auch, aber garantiert funktionieren tut das nur, wenn du wirklich nur byteweise zugreifst.

    Bei 32bit kann ich ja IMHO ca. 4GB speicher addressieren. Eine Konsequenz deiner Aussage währe ja doch dann, dass ich ca. 16BG adressieren könnte, aber halt nur jedes 4te Byte?

    Nein. Die Konsequenz ist, dass ein 32-Bit-Wert nur dann in einem 32-Bit-Zugriff gelesen werden kann, wenn er an durch 4 teilbaren Adressen liegt. Der Adressraum bleibt gleich groß.

    Viele Tutorials und Bücher, die ich gelesen habe und die Verarbeitung von Binärdaten behandeln, lesen und schreiben direkt in und aus Strukturen aus oder in Dateien...

    In vielen Tutorials und Büchern steht halt Müll drin. 🙂

    0
  • R

    Janjan schrieb:

    Darauf musst du dank Standard in deinem Code nicht achten, darauf muss der Compiler für dich achten. 😉

    reinterpret_cast heißt aber auch "ich weiß was ich hier tue, lass mich mal machen".

    Ishildur schrieb:

    @Janjan
    Puuhhhh.... Dank dir kann ich wieder ruhig schlafen 😃

    Nur weil er sagt was du hören willst, hat er noch lange nicht recht. 🙂

    0
  • I

    @Registrierter Troll
    Ok, kannst du mir ein Codebeispiel geben, wie ich folgende Daten "korrekt" auslese:
    Ich habe einen Zeiger auf eine Speicheradresse, welche folgende Daten enthält:
    1Byte,2Byte,8Byte,1Byte,4Byte,2Byte
    Diese muss ich nun in eine Struktur abfüllen oder auf den Bildschirm oder was weis ich. Die Grösse des Zeigers darfst du selber wählen...

    0
  • ?

    Registrierter Troll schrieb:

    Janjan schrieb:

    Darauf musst du dank Standard in deinem Code nicht achten, darauf muss der Compiler für dich achten. 😉

    reinterpret_cast heißt aber auch "ich weiß was ich hier tue, lass mich mal machen".

    ZeigerTyp *zeiger = ...;
reinterpret_cast<int*>(zeiger);

    Das heißt, ich weiß was ich mache, ich weiß dort liegen _int_ Daten für mich, also mecker nicht.

    0
  • I

    @Registrierter Troll

    Dieser Code wäre dann aber IMHO nach deiner Aussage auch "gefährlich" ?

    uint32* p32 = new uint32[512];
uint8*  p8 = reinterpret_cast<uint8*>(p32);
uint8  val  = p8[3];

    Denn dieser Code kopiert nun das dritte Oktett des ersten Integers in Val, das ja nun sicher nicht mehr 32bit aligned ist...

    0
  • R

    Ishildur schrieb:

    Ok, kannst du mir ein Codebeispiel geben, wie ich folgende Daten "korrekt" auslese:

    Das wirklich richtig zu machen ist nicht mit ein paar Zeilen getan, und da ich mir nicht hundertprozentig sicher bin ob ich in diesem Fall wirklich recht habe, lasse ich das lieber mal. Es würde vermutlich auf etwas hinauslaufen, was ähnlich der zweiten Antwort (I have to disagree with many of the responses here...) auf eine ähnliche Frage bei Stack Overflow ist.

    Du kannst ja mal selbst im Standard die Abschnitte 3.10.15 und 5.2.10 durchlesen und mit all ihren Implikationen verstehen, dann siehst du warum das nicht so einfach ist.

    Denn dieser Code kopiert nun das dritte Oktett des ersten Integers in Val, das ja nun sicher nicht mehr 32bit aligned ist...

    Es spielt keine Rolle, wie der Speicher angelegt wurde. Der Zugriff ist entscheidend. Ausgehend von der Annahme, dass uint8 ein [unsigned] char ist und geringere Anforderungen an das Alignment stellt, ist der Zugriff in Ordnung:

    3.10.15 schrieb:

    15 If a program attempts to access the stored value of an object through an lvalue of other than one of the fol-
    lowing types the behavior is undefined:
    — the dynamic type of the object,
    — a cv-qualified version of the dynamic type of the object,
    — a type that is the signed or unsigned type corresponding to the dynamic type of the object,
    — a type that is the signed or unsigned type corresponding to a cv-qualified version of the dynamic type of
    the object,
    — an aggregate or union type that includes one of the aforementioned types among its members (includ-
    ing, recursively, a member of a subaggregate or contained union),
    — a type that is a (possibly cv-qualified) base class type of the dynamic type of the object,
    — a char or unsigned char type.

    Janjan schrieb:

    ZeigerTyp *zeiger = ...;
reinterpret_cast<int*>(zeiger);

    Das heißt, ich weiß was ich mache, ich weiß dort liegen _int_ Daten für mich, also mecker nicht.

    Wenn du dir die entsprechenden Stellen im Standard durchliest, wirst du sehen dass es so einfach nicht ist.

    0
Anmelden zum Antworten