records im Speicher...

[SnuffMaster23]

Es geht um dieses record:

• http://www.abload.de/img/guck8fg.jpg

Wieso sieht das im Speicher denn so aus

• http://www.abload.de/img/guckjxl.jpg

und nicht so?

• http://www.abload.de/img/guckjs2.jpg

Das ist zum einen Platzverschwendung und zum anderen richtig unpraktisch wenn man aus einer Datei lesen möchte.
Gibts da nen Trick um das zusammenzuschieben?

[Corpsman]

Hast du mal Packed Record probiert ?

[Phoenix]

Probier mal nicht record sondern packed record zu benutzen.

Edit: Mann ist Corps heute wieder schnell ;-)

[SnuffMaster23]

jo damit gehts!
Mann seid ihr schnell :D
Danke!

[Luckie]

Warum beantwortet ihr seine Frage nicht?

Der Delphi Compiler richtet die Felder des Records an Byte-Grenzen aus. Dies optimiert den Zugriff auf die Speicherbereiche, da die CPU sowieso immer 4 Byte (bei einer 32-Bit CPU) aus dem Speicher lädt. Sind die Felder an Byte-Grenzen ausgerichtet, ist es für die CPU "einfacher" die wirklich benötigten Bytes zu extrahieren. Der zusätzlich benötigte Speicherplatz ist heute vernachlässigbar. Die Ausrichtungsgrenze kann in den Compiler Optionen eingestellt werden.

Will sicherstellen, dass kompatible Records auch mit einer anderen Ausrichtungsgrenze erstellt werden, kann man mit dem Schlüsselwort packed die Ausrichtung der Felder an Byte-Grenzen verhindern. Dabei kommt dann das raus, was du eigentlich erwartet hattest.

[Phoenix]

Deswegen hatte ich den Link noch in meiner Antwort drin. Da steht das auch nochmal kurz und knapp erklärt drin ;-)

[SnuffMaster23]

Den Link hab ich auch erst auf den zweiten Blick gesehen^^

Aber wenn wir schonmal dabei sind:
Ist es schlimm mit

Delphi-Quellcode:

TID3v2FrameHeader = record
  FrameID: array[0..3] of Char;
  Size:    Integer;
  Flags:   Word;
end;

Delphi-Quellcode:

f.ReadBuffer(FHeader, 10);

zu schreiben?

[Klaus01]

Vielleicht ist es so besser?

Delphi-Quellcode:

f.ReadBuffer(FHeader,SizeOf(TID3v2FrameHeader));

Grüße
Klaus

[Dax]

Ja, und wie. Stell dir vor, dein Compiler ändert seine Alignment-Grenzen auf zb 16 Byte. Dann ist deine Struktur wieder aufgebläht und nicht zum lesen zu gebrauchen... Daher benutze packed und sizeof!

[SnuffMaster23]

Nein Klaus, mit SizeOf ist es nicht besser, dann liests mir ja 2 Bytes zu viel weg.
Genau das war ja die Frage, ob es schlimm ist die zwei Bytes hinten dran nicht 'vollzulesen'.

@Dax: joa, man kann ja nie wissen was dem Compiler auf einmal einfällt :lol:
Mir ist schon klar dass es mit packed und SizeOf richtig ist, das mit den 10 war nur meine Notlösung. Funktioniert hat sie ja :D

Hätt ich ja eigentlich selber draufkommen können... mit nem 64-Bit Compiler wärs wahrscheinlich schon schiefgegangen.

[Reinhard Kern]

Zitat:

Zitat von SnuffMaster23

Nein Klaus, mit SizeOf ist es nicht besser, dann liests mir ja 2 Bytes zu viel weg.
....

Wieso das denn?

1. Antwort nicht gelesen - packed UND SizeOf.

2. Prinzip nicht verstanden - man kann einen Record nur lesen, wenn er identisch aufgebaut ist, d.h. wenn er in der Datei gepackt ist (meistens), dann ist auch im Programm NUR UND AUSSCHLIESSLICH packed korrekt. Bei unterschiedlichem Aufbau könnte man nur die Komponenten des Records einzeln einlesen.

Gruss Reinhard

[SnuffMaster23]

na weil aus
array[0..3] of Char + Integer + Word
wird
array[0..3] of Char + Integer + Word + 2 Bytes

1. Frage nicht richtig gelesen ;)
   Es geht um ein anderes record
2. Prinzip verstanden, hab doch nur ohne zu überlegen nach meiner Notlösung gefragt^^ :roll:

[Muetze1]

Wenn du packed angeben würdest, dann würde er kein Alignment durchführen bei dem Record und somit wäre der Record auch nicht 2 Byte grösser als du ihn definierst. Somit Frage nicht umgesetzt: packed und sizeof. Wurde aber schon gesagt.

@Luckie: Deine Ausführungen sind etwas schlecht formuliert, weil wenn er an Bytegrenzen ausrichten würde, dann bräuchte er kein Aligment, da Byte = 8 Byte. Sagen wir lieber, er richtet an DoubleWord-Grenzen aus.

[Luckie]

Zitat:

Zitat von Muetze1

Sagen wir lieber, er richtet an DoubleWord-Grenzen aus.

Nach dem Ausdruck habe ich die ganze Zeit gesucht, als ich den Beitrag geschrieben habe. Danke für die Verbesserung.

[Phoenix]

Zitat:

Zitat von Muetze1

Sagen wir lieber, er richtet an DoubleWord-Grenzen aus.

Auch nicht ganz richtig. Der Compiler richtet die Datentypen anhand der Größe der Datentypen aus.

Wenn Du nur Bytes hast werden die nach Bytes ausgerichtet.

Hast Du z.B. ein Byte und einen LongInt würde er den LongInt am nächsten "LongInt" vom an Beginn ausrichten - also am 4. Byte. Du hättest dann 3 Byte unverwendeten Speicher.
"Byte", "unverw. Byte", "unverw. Byte", "unverw. Byte", "LongInt".
<--- 4 Byte = SizeOf(LongInt) --->, LongInt.

[Muetze1]

Nö, er richtet es nach seiner eigenen Verarbeitungsgrösse aus. Da wir (noch) ein 32 Bit Delphi nutzen, richtet er es an einer durch 4 teilbaren Adresse aus und sorgt innerhalb des Records dafür, dass die Elemente genauso aligned werden. Ab D6 kann man mit dem Compilerschalter sogar angeben, welches Alignment er verwenden soll: $ALIGN [2|4|8]. Grundsätzlich nutzt er aber erstmal eine durch 4 teilbare Adresse.

D5 und zuvor war nur $ALIGN ON|OFF möglich, wobei ON = 4 war. D1 als 16 Bit Compiler lasse ich mal aussen vor.

Zitat:

Zitat von Phoenix

Zitat:

Zitat von Muetze1

Sagen wir lieber, er richtet an DoubleWord-Grenzen aus.

Auch nicht ganz richtig. Der Compiler richtet die Datentypen anhand der Größe der Datentypen aus.

Wenn Du nur Bytes hast werden die nach Bytes ausgerichtet.

Hast Du z.B. ein Byte und einen LongInt würde er den LongInt am nächsten "LongInt" vom an Beginn ausrichten - also am 4. Byte. Du hättest dann 3 Byte unverwendeten Speicher.
"Byte", "unverw. Byte", "unverw. Byte", "unverw. Byte", "LongInt".
<--- 4 Byte = SizeOf(LongInt) --->, LongInt.

Dass würde nach deinem Beispiel bei folgendem:

Delphi-Quellcode:

  TRec = record
    i: longint;
    a: byte;
  end;

also eine Grösse von 5 bedeuten? Nein, leider nicht. Er ist 8 Byte gross. ABER: er richtet es immer nach dem grössten Element im Record aus. Weil z.B.:

Delphi-Quellcode:

  TRec = record
    i: double;
    a: byte;
  end;
  TRec2 = record
    i: byte;
    a: double;
  end;

beide 16 Byte gross sind. Würde jetzt anstatt Double dort Word stehen, dann wäre Word das grösste Element und er würde bei beiden Records auf eine Grösse von 4 Bytes kommen.