Zugriff auf Variante Teile in Record-Typen

[ma2xx]

Beim Zugriff auf die Varianten Teile eines Records sollten diese normalerweise auf der gleichen Adresse liegen, oder?

Delphi-Quellcode:

TTest = record
    case Typ:Boolean of
    false: (T1     :Integer);
    true:  (T2     :Double);
  end;

Die Adresse von T2 ist 4 Bytes größer als die Adresse von T1! Wieso?
Da es kein packed record ist gehe ich davon aus, dass der Compiler die varianten Teile des Records gleich ausrichtet (Compilerschalter "Recordfelder ausrichten" ein [Delphi5] bzw. auf 8 [Delphi7 und Delphi2005]).

Ändert man obriges Record wie folgt, dann ergeben sich gleiche Adressen für T1 und T2:

Delphi-Quellcode:

TTest = record
    Dummy: Integer;
    case Typ:Boolean of
    false: (T1     :Integer);
    true:  (T2     :Double);
  end;

Hintergrund:
Meine Anwendung übergibt ein (sinnvolles) Record einer DLL die in C++ geschrieben ist. Die DLL definiert das gleiche Record, wobei der Variante Teil als "union" definiert wird. Interessanterweise richtet der C++ Compiler bei varianten Teile des Record gleich aus. Da es Delphi nicht gleich ausrichtete kommt es zu einer Verschiebung um 4 Bytes beim Zugriff auf Teil mit der kleineren Adresse. Das original Record definiert übrigens im varianten Teil weitere Records. Die Beispiele habe ich exemplarisch vereinfacht um das Problem zu verdeutlichen.

Für eine Erklärung wäre ich dankbar.

[NicoDE]

Zitat:

Zitat von ma2xx

Delphi-Quellcode:

TTest = record
    case Typ:Boolean of
    false: (T1     :Integer);
    true:  (T2     :Double);
  end;

Probier's mit...

Delphi-Quellcode:

type
  TTest = record
    Typ    : Boolean;
    case Boolean of
      False: (T1: Integer);
      True : (T2: Double);
  { end; }
  end;

...ist das gleiche in grün.

[ma2xx]

Korrekt, ist das selbe:

Debugger meldet
@Test.T1: $12F3E8
@Test.T2: $12F3EC
wobei var Test:TTest;

... immernoch 4 Byte unterschied!

[himitsu]

Eventuell richtet Delphi den Record andersrum aus, obwohl dieses eigentlich falsch wäre?

Versuch es mal so (Variante Teile mit der selben Größe):

Delphi-Quellcode:

TTest = record 
  case Typ: Boolean of 
    false: (T1, dummy: Integer); 
    true:  (T2:        Double); 
  end;

oder:

Delphi-Quellcode:

TTest = packed record 
  case Typ: Boolean of 
    false: (T1, dummy: Integer); 
    true:  (T2:        Double); 
  end;

[ma2xx]

Variante 1 - Fehler:
@Test.Typ: $12F3E4
@Test.T1: $12F3E8
@Test.T2: $12F3EC

Variante 2 - OK, aber ist ja auch packed record:
@Test.Typ: $12F3EB
@Test.T1: $12F3EC
@Test.T2: $12F3EC

... Ziel ist es ohne Dummy auszukommen UND ohne packed (C++ DLL, die das Record verarbeitet, ist auch nicht packed)

[NicoDE]

Ich würde mich nicht auf das Alignment verlassen (ist auch der Grund für den Compiler-Bug).
Du solltest die Struktur als 'packed' deklarieren und die Zwischenräume durch die benötigte 'Ausrichtung' mit Variablen füllen...

Ein Workaround könnte so aussehen:

Delphi-Quellcode:

type
  TTest = record
    case Integer of
      0: (Typ     : Boolean);  // LongBool? (check C/C++ code)
      1: (Reserved: Double;    // Alignment
  { end; }
    case {Typ: }Boolean of
      False: (T1: Integer);
      True:  (T2: Double));
  { end; }
  end;

edit:

Zitat:

Zitat von ma2xx

... Ziel ist es ohne Dummy auszukommen UND ohne packed

Wird wegen des Compiler-Bugs nicht gehen...

ps: muss es denn auf der C/C++-Seite unbedingt eine unbenannte Union sein? (ist ohnehin nicht standard-konform...)

[ma2xx]

Als Workaround kann ich natürlich alle records auf gerade Adressen trimmen indem ich Dummy-Bytes einführe. Das ist auch die derzeitige Lösung. Leider besteht das original Projekt aus ein paar Duzend Records die miteinander verschachtelt sind. Hier manuell eine Ausrichtung auf die korrketen Adressen durchzuführen ist aufwendig und frustrierend. Ich denke schon, dass das die Aufgabe des Compilers ist. Ich hoffe immernoch auf eine Lösung per Compiler (der lieben Codesicherheit wegen) bzw. einer Erklärung, ob diese krumme Adressausrichtung möglicherweise beabsichtigt ist.

[NicoDE]

Zitat:

Zitat von ma2xx

Ich denke schon, dass das die Aufgabe des Compilers ist.

Ist es auch, aber er ist nicht perfekt ;)
Ich habe meinen letzten Beitrag editiert; kanst du bitte die Frage nach den unbenannten Unions beantworten?

[ma2xx]

Zitat:

Zitat von NicoDE

ps: muss es denn auf der C/C++-Seite unbedingt eine unbenannte Union sein? (ist ohnehin nicht standard-konform...)

Ich bin nicht so vertraut mit der C++ Seite (gibt es auch andere Unions?), denn die DLL ist nicht von mir. Prinzipell sollten die Records in der DLL aber ausgerichtet verarbeitet werden, denn es ist eine schnelle Laufzeit gewünscht (Bildverarbeitungsfunktionen). Ich muss mich also nach der DLL richten.

[himitsu]

ahh, es könnte tatsächlich an der Speicherausrichtung liegen ^^

Code:

Boolean/ByteBool:
************************  // Ausrichtung alle 1 Byte

Integer/LongInt:
*---*---*---*---*---*---  // Ausrichtung alle 4 Byte

Double:
*-------*-------*-------  // Ausrichtung alle 8 Byte
        
unpacked:
*   *---          // Boolean + Integer
*       *-------  // Boolean + Double

packed:
**---             // Boolean + Integer
**-------         // Boolean + Double