Zugriff auf Variante Teile in Record-Typen

[NicoDE]

Zitat von ma2xx:

(gibt es auch andere Unions?)

Jupp:

Code:

union {
    int     T1;
    double  T2;
} u1;

Würde übersetzt werden mit:

Delphi-Quellcode:

u1: record
  case Boolean of
    False: (T1: Integer);
    True:  (T2: Double);
{ end; }
end;

...unbenannte Unions sind eine Strafe für jeden Entwickler der C/C++ nach Delphi portieren muss...

[ma2xx]

Es ist offensichtlich, dass das Problem die Speicherausrichtung ist.

Delphi-Quellcode:

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

- TTest wird je nach Compilerschalter gerade ausgerichtet (Startadresse)
- Typ (Boolean) ist 1Byte lang (wäre es ein Aufzählungstyp, dann auch 1Byte, es sei denn man aktiviert {$Z4} (4Bytes))
- Es folgt speicherüberlappend T1 (4Bytes lang) und T2 (8Bytes lang) -> nur warum nicht an der gleichen Anfangsadresse???

@Nico Bendlin
Der Code in C++ sieht wie folgt aus (wenn ich mich nicht irre)

Code:

struct {
  Bool      Typ;
  union {
    int     T1;
    double  T2;
  };
} TTest;

Jedenfalls ist hier die Adresse von T1 == Adresse von T2!
Siehe hierzu: MSDN Figure 8.1 Storage of Data in NumericType Union

[NicoDE]

Zitat von ma2xx:

nur warum nicht an der gleichen Anfangsadresse?

Weil der Delphi-Compiler den varianten Teil der Struktur offensichtlich nicht als Einheit betrachtet und die Ausrichtung jeweils einzeln für die Mitglieder der 'Union' berechnet (dies ist wahrscheinlich nicht das, was die meisten Entwickler erwarten würden - kurz, man könnte es als Bug bezeichnen (ich kenne die Delphi-Dokumentation nicht auswendig )).

Zitat von ma2xx:

Der Code in C++ sieht wie folgt aus (wenn ich mich nicht irre)

Ja, leider...
...in einer Typ-Definition haben anonyme Unions eigentlich nichts zu suchen.
( siehe http://msdn.microsoft.com/library/de...m/class_33.asp )

Es wäre besser gewesen, wenn die Deklaration so ausgesehen hätte:

Code:

typedef struct tag_TTest {
  bool      Typ;
  union {
    int     T1;
    double  T2;
  } u1;
} TTest, * PTest;

Wie auch immer, es hält dich niemand davon ab, die Struktur in Delphi anders zu übersetzen (zum Beispiel mit u1 als inline-record)...

[himitsu]

Zitat von ma2xx:

nur warum nicht an der gleichen Anfangsadresse???

Weil die vermutlich an einer ihrem Typ entsprechenden Stelle ausgerichtet werden. (siehe meinen letzten Beitrag)

[ma2xx]

Nunja, wir kommen wohl nicht weiter ...

Mein Eindruck ist, dass hier ein Delphi-Bug vorliegt.
Meine Versuche zeigten, dass die Anfangsadressen von T1 und T2 abhängig von der Position des Typ sind, egal ob der Typ vor der case oder in der case steht. Es ist auch egal wie lang die varianten Teile des Record sind.
Es bleibt also als Workaround nur das Einfügen von Bytes bis ein gerade Adresse vorliegt (getestet und OK) oder die Verwendung eines weiteren lokalen record um die case (getestet und OK, aber dadurch lokaler Bezeichner -> umständlich).
Die Deklaration der union in C++ ist davon unabhängig. Hier liegen in allen Varianten gleiche Adressen vor!

Vielleicht werde ich mal bei Borland nachfragen ...
Danke für die Diskussion.

[Christian Seehase]

Moin ma2xx,

je nach Delphi-Version könntest Du es auch einmal mit $A bzw. $ALIGN probieren den Compiler zum "mitspielen" zu bewegen.

[NicoDE]

Zitat von Christian Seehase:

je nach Delphi-Version könntest Du es auch einmal mit $A bzw. $ALIGN probieren den Compiler zum "mitspielen" zu bewegen.

Bringt in dem Fall nichts (der Bug entsteht dadurch, dass die Ausrichtung für jedes Mitglied des varianten Teils der Struktur neu berechnet wird...).

[himitsu]

{$A-}, {$A1}, oder {$ALIGN OFF} sollte wohl helfen?

Zitat von OH:

Wenn ein Record-Typ mit dem voreingestellten Status {$A+} deklariert wird und die Deklaration nicht den Modifizierer packed enthält, handelt es sich um einen ungepackten Record-Typ. Die Felder des Records werden so ausgerichtet, dass die CPU möglichst effizient darauf zugreifen kann. Die Ausrichtung hängt von den Typen der einzelnen Felder ab und davon, ob Felder zusammen deklariert werden. Jeder Datentyp besitzt eine implizite Ausrichtungsmaske, die vom Compiler automatisch berechnet wird. Sie kann die Werte 1, 2, 4 oder 8 haben und entspricht dem Byte-Raster, in dem ein Wert dieses Typs für den optimalen Zugriff im Speicher angeordnet werden muss. Die folgende Tabelle enthält die Ausrichtungsmasken für alle Datentypen.
...
Wenn ein Record-Typ mit dem Status {$A–} deklariert wird oder die Deklaration den Modifizierer packed enthält, werden die Felder des Records nicht ausgerichtet, sondern einfach an aufeinander folgenden Offsets abgelegt.

Themen in der OH > "$ALIGN" oder auch "Felder ausrichten (Compiler-Direktive)"
wobei hierfür der Abschitt "Record-Typen" (wird von dem oben angegebenen Abschitt weiterverlinkt) zutreffender ist.

[NicoDE]

Zitat von himitsu:

{$A-}, {$A1}, oder {$ALIGN OFF} sollte wohl helfen?

Nope, weil die Aufgabe war/ist, ohne Hilfsvariablen die selbe Ausrichtung wie in der Referenzstruktur zu erreichen (und das geht, wie oben bereits mehrmals festgestellt, nicht).

[ma2xx]

Ich bin für neue Ideen immer dankbar ...
Wenn ich folgenden Code teste ...

Delphi-Quellcode:

TTest = record
    case Typ:Boolean of
{$A-}
    false: (T1     :Integer);
    true:  (T2     :Double);
{$A+}
end;

... dann erhalte ich tatsächlich gleiche Adressen für T1 und T2:
@Test.T1: $12F3D5
@Test.T2: $12F3D5
Diese Vorgehensweise macht prinzipiell Sinn, wenn man sich als Programmierer dem Problem unterschiedlicher Adressen für die varianten Teile des Records bewusst ist (zumindest muss ich nicht alle Records manuell nachrechnen). Nur jetzt muss man noch klären, ob C++ für die varianten Teile immer eine gerade (ausgerichtete) Adresse standardmäßig verlangt, denn wie unschwer zu erkennen, sind in meinem Beispiel die Adressen ungerade. Ich werde das auch nochmal klären ...