records im Speicher...

[Reinhard Kern]

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^^

[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 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 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 von Phoenix:

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.