Variante Records, Strings und 32 bzw. 64 Bit

[Codehunter]

Gudn Namd :-)

Zu später Stunde eine Frage zum Thema variante Records. Ich habe folgende Record-Definition:

Delphi-Quellcode:

  TVarStr = record
    case X: Boolean of
      TRUE:
      (
        Str: string[32];
      );
      FALSE:
      (
        P1: string[6];
        P2: string[6];
        P3: string[6];
        P4: string[6];
        P5: string[6];
        P6: string[2];
      );
  end;

Wenn ich dem Record dann einen Wert zuweise, etwa so:

Delphi-Quellcode:

var
  X: TVarStr;
begin
  X.Str:= '306E096DADF14AFDA5E4B22A17EC50D4';
end;

Dann erhalte ich bei folgendem Versuch:

Delphi-Quellcode:

var
  X: TVarStr;
begin
  X.Str:= '306E096DADF14AFDA5E4B22A17EC50D4';
  ShowMessage(X.P1);
end;

nicht etwa wie ich erwarten würde "306E09" als Anzeige, sondern "306E096DADF14AFDA5E4B22A17EC50D4", also den ganzen String mit 32 Zeichen. Wenn ich gleichermaßen auf X.P6 zugreife, lande ich vom Speicherzeiger her hinter dem String und bekomme Datenschrott von 32 Bytes Länge zurück. Interessanterweise scheint sich die Position des Zeigers in dem Fall auch noch unterschiedlich zu verschieben, je nachdem ob ich für 32 oder 64 Bit compiliere. Wo mache ich da jetzt den Denkfehler?

Grüße
Cody

[Uwe Raabe]

Bei einem ShortString steht die aktuelle Stringlänge im ersten Byte. Danach folgen die einzelnen Zeichen (AnsiChar) bis zu der maximalen Länge. P1 und str liegen auf demselben Speicherbereich. Schreibst du auf str einen String von z.B. 20 Zeichen, steht im Längenbyte von P1 ebenfalls eine 20. Die Adressen von P2..P6 decken sich wegen der jeweiligen Längenbytes nicht mit den von dir erwarteten String-Positionen. Zusätzlich schlägt noch das Record-Alignment zu, das die Startadressen der Felder auf bestimmte Bytegrenzen legt.

Kurz: was du da vorhast geht so nicht.

[Codehunter]

Ok, ich bin davon ausgegangen, dass durch die explizite Angabe von Längen im Record kein Längenbyte an Position 1 der einzelnen Elemente mehr verwendet würde, da die Länge ja nun mal fix vorgegeben ist. Nun ja, falsch gedacht ^^

Gibts da eine alternative elegante Herangehensweise ohne wieder in Stapel von Copy-Befehlen zu verfallen?

[himitsu]

Delphi-Quellcode:

string[12]

ist intern so aufgebaut:

Delphi-Quellcode:

array[0..12] of AnsiChar; 

// bzw.

record
  Length: Byte{AnsiChar};
  array[1..12] of AnsiChar; 
end;

Und jetzt überleg mal, was da mit dem Langenbyte bei dir passiert.
Und dazu kommt eventuell noch, daß deine Strings auch noch im Speicher ausgerichtet sein könnten (z.B. erst an der nächsten Integer-Grenze beginnen)

[himitsu]

PS: Seit Delphi 2006 kann man auch Methoden und Property in den Records verbauen.

Delphi-Quellcode:

type
  TVarStr = record
  private
    function ReadPart(StartLength: Integer): AnsiString;
  public
    Value: string[32];  // es gibt eine Funktion mit dem Namen "Str" ... siehe "Val"
    property P1: AnsiString index 0106 read ReadPart;
    property P2: AnsiString index 0706 read ReadPart;
    property P3: AnsiString index 1306 read ReadPart;
    property P4: AnsiString index 1906 read ReadPart;
    property P5: AnsiString index 2506 read ReadPart;
    property P6: AnsiString index 3102 read ReadPart;
  end; 

function TVarStr.ReadPart(StartLength: Integer): AnsiString;
begin
  Result := Copy(Value, StartLength div 100, StartLength mid 100);
end;

Ansonst mußt du statt

Delphi-Quellcode:

string[x]

jeweils ein

Delphi-Quellcode:

array[0..x-1] of AnsiChar

verwenden.

[Codehunter]

Hui, gute Idee! Ich versteh zwar bis heute noch nicht, was den Record in dem Fall dann noch von einer Klasse unterscheidet. Außer dass er nicht per Constructor instantiiert werden muss. Jedenfalls wird so aus dem Stapel von Copys nur noch eins.

Gut war jetzt im Grunde ein banales Beispiel für ein komplexeres Problem, aber das wichtigste ist dass ich wiedermal was gelernt hab. Danke schön und gute Nacht für heute!

[himitsu]

Bei einem Record hast du quasi direkt den Zugriff auf den internen Speicher. und man könnte es direkt in einen Stream/Datei speichern. (außer wenn gewisse gemanagte oder gepointerte Typen drin vorkommen)

[OlafSt]

Gibt es für das Konstrukt "AnsiString index XXXX" irgendwo eine Dokumentation ? Irgendwie beschleicht mich das Gefühl, extrem viel verpaßt zu haben:pale:

[himitsu]

Das sollte bei "Property" in der OH stehen und das gibt es schon sehr sehr lange. (in den Objekten und Interfaces)
Nur bei Records wurde es erst später eingeführt. Genauso, wie es Class- und Record-Helper erst seit einer Weile gibt.

Index ist einfach ein Integer-Parameter, den man an den Getter und Setter weitergeben kann.

Delphi-Quellcode:

[class] function DerGetter([ArrayParameter: ParamTyp; ...] [IndexParameter: Integer]): ResultTyp; [static;] [overload;] [virtual|dynamic; [abstract;]] [override;]
[class] procedure DerSetter([ArrayParameter: ParamTyp; ...] [IndexParameter: Integer; ] Value: ResultTyp); [static;] [overload;] [virtual|dynamic; [abstract;]] [override;]

// Array-Property
[class] property DerName[ArrayParameter: ParamTyp; ...]: ResultTyp [index IndexParameter] [read DerGetter] [write DerSetter] [default];

// normales Propery
[class] property DerName: ResultTyp [index IndexParameter] [read DerGetter] [write DerSetter] [default DerStandardwert];

// [...] = das darin Eingeschlossene ist optional
// außer um den "ArrayParameter" drumrum, da sind wirklich die Zeichen [ und ] gemeint

Nur beim "default" muß man aufpassen, da es bei Array-Property das Property als Standard-Property deklariert .... siehe TStrings (

Delphi-Quellcode:

SL.Strings[123] = SL[123]

)
und bei normalen Properties die Serialisierung steuert ... also den Wert, welchen z.B. die VCL nicht in der DFM speichert.

Virtual, dynamic, abstract, override und natürlich auch das protected nicht bei Records, da diese keine Vererbung besitzen.

[OlafSt]

*koppklatsch* Natürlich... Einfach nur ein cleveres Ausnutzen eines uralten und wenig benutzten Features. Danke für die Aufklärung :thumb: