Bug bei {$ALIGN} in Delphi 7?

[Christian Seehase]

Moin Zusammen,

durch eine Thread von Pseudemys Nelsoni (Diese C-Struktur in Delphi? kam ich darauf mal die Direktive {$ALIGN} zu testen.

Standardmässig wird in D7 ja ein Alignment von 8 eingestellt, so dass ein Record wie dieser

Delphi-Quellcode:

type
  TEinRecord = record
    Ptr1  : Pointer;
    Feld1 : cardinal;
    Feld2 : cardinal;
  end;

bei SizeOf eigentlich 24 zurückliefern müsste.

Das passiert aber nicht. Die Grösse ist 12.

Als Direktive habe ich es auch einmal direkt vor die Recorddeklaration geschrieben, um sicherzustellen, dass auch tatsächlich 8 eingestellt ist, allerdings ohne Erfolg. Es blieb bei Size = 12.

Mach' ich da jetzt einen Denkfehler?

[sakura]

Ich denke mal, dass die Lösung im Handling liegt. Der Delphi Language Guide (Record Types) erklärt es so:

To ensure proper alignment of the fields in an unpacked record type, the compiler inserts an unused byte before fields with an alignment of 2, and up to three unused bytes before fields with an alignment of 4, if required. Finally, the compiler rounds the total size of the record upward to the byte boundary specified by the largest alignment of any of the fields.

If two fields share a common type specification, they are packed even if the declaration does not include the packed modifier and the record type is not declared in the {$A-} state. Thus, for example, given the following declaration

type
TMyRecord = record
A, B: Extended;
C: Extended;
end;

A and B are packed (aligned on byte boundaries) because they share the same type specification. The compiler pads the structure with unused bytes to ensure that C appears on a quadword boundary.

......

[Christian Seehase]

Moin Daniel,

was dann aber der Dokumentation von $ALIGN wiederspricht:

Zitat:

In the {$A8} or {$A+} state, fields in record types that are declared without the packed modifier and fields in class structures are aligned on quad word boundaries.

[jbg]

Bei A8 werden 64Bit große Datentypen auf 8 Byte ausgerichtet. Zwei 32Bit Datentypen passen nämlich in 8 Byte rein.

Wenn man z.B einen Record mit einem Byte gefolgt von einem Int64 hat, dann werden 7 Bytes eingefügt, damit der Int64 auch an 8 Byte ausgerichtet ist. Hat man hingegen statt dem In64 einen Int32, dann kann dieser, seiner Größe entsprechend, an eine 4 Byte Grenze ausgerichtet werden. Einen Geschwindigkeitsvorteil bei einer 8 Byte Ausrichtung des Int32 erlangt man nämlich nicht, weil es vollkommen egal ist, ob nun die 4 Bytes davor oder die 4 Bytes danach als überflüssige Lese/Schreib-Zugriff benötigt werden.