Frage zu den "neuen" Records in 10.4

[Der schöne Günther]

Ich habe die Entwicklung nicht wirklich mitverfolgt, jetzt sind sie da.

Was mir auffällt ist dass früher ™ bei

Delphi-Quellcode:

meinRecord1 := meinRecord2

die Felder kopiert wurden, mehr nicht. Sieht beispielsweise mein Record so aus

Delphi-Quellcode:

TMyRecord = record
  someByte: Byte;
  someInteger: Integer
end;

dann sind zwischen dem Byte und dem Integer (bei üblicher Compiler-Optimierung) 3 "Padding-Bytes" Platz. Die wurden nicht mitkopiert. Jetzt scheint das der Fall zu sein.

Hat das einen Grund? Muss ich mich vorsehen?

Ich habe unter
http://docwiki.embarcadero.com/RADSt...anaged_Records
nichts darüber gefunden.

[Rollo62]

Schonmal mit packed records probiert ?
Ich verstehe das so dass Alles wie bisher bleiben soll,
Nur das man zusätzlich selbst noch das Kopierverhalten steuern kann.

Im Default müsste man aber nichts anfassen, damit es kompatibel zu altem Code bleibt.
Ich habe aber noch nicht explizit damit rumprobiert, sondern versuche erstmal Projekte komplett zu portieren und zu testen.

[Der schöne Günther]

Bei

Delphi-Quellcode:

packed record

gibt es gar kein Padding, das ist ja der Sinn der Dinger.

Ich habe ja auch gar kein konkretes Problem das ich lösen muss (außer dass unter 10.4 jetzt ein paar Unit-Tests fehlschlagen), ich würde nur gerne wissen ob jemand evtl. ein Beispiel vorstellen kann, wo das neue Verhalten eine Rolle spielt.

[Rollo62]

Was genau meinst Du mit "mitkopiert" ?

Ist vorher Padding drin, hinterher nicht ?

[freimatz]

Zitat:

Zitat von Der schöne Günther (Beitrag 1467188)

...ich würde nur gerne wissen ob jemand evtl. ein Beispiel vorstellen kann, wo das neue Verhalten eine Rolle spielt.

Nur wenn man extrem unsauber programmiert.

[Daniel]

Mit unsauberem Stil hat das nichts zutun.
Die neuen Möglichkeiten für Records erlauben es, diese z.B. automatisch zu initialisieren - mit Werten Deiner Wahl. Und über den Assign-Operator lässt sich das Kopier-Verhalten steuern. Gerade bei komplexen Typen kann hier Bedarf entstehen.

[Redeemer]

Zitat:

Zitat von Der schöne Günther (Beitrag 1467188)

ich würde nur gerne wissen ob jemand evtl. ein Beispiel vorstellen kann, wo das neue Verhalten eine Rolle spielt.

In die angegebene Richtung sollte es keine Probleme geben, aber in die Gegenrichtung.

[Sinspin]

Zitat:

Zitat von Der schöne Günther (Beitrag 1467177)

... 3 "Padding-Bytes" Platz. Die wurden nicht mitkopiert. Jetzt scheint das der Fall zu sein. ...

Die wurden nicht mitkopiert? Ernsthaft?
Das hätte ja bedeutet das der Vorteil des einfacheren Zugriffs hinweg gewesen wäre bei jedem Kopiervorgang. Denn via Move einfach den Speicher von A nach B kopieren ist doch viel schneller als jedes einzelne Feld des Records unter Beachtung seines Datentyps einzeln zu kopieren. Das würde ich mit Schildbürgertum vom feinsten vergleichen. ... und kann ich mir nicht vorstellen.

[jaenicke]

Zitat:

Zitat von Der schöne Günther (Beitrag 1467177)

dann sind zwischen dem Byte und dem Integer (bei üblicher Compiler-Optimierung) 3 "Padding-Bytes" Platz. Die wurden nicht mitkopiert. Jetzt scheint das der Fall zu sein.

Wenn sie in irgendeiner Version einmal nicht mit kopiert wurden, war das ein Bug. Ich konnte allerdings keine solche Version finden (XE, XE6, 10.2, 10.3 und 10.4 kopieren alle korrekt den kompletten Speicherinhalt).

[Der schöne Günther]

Zitat:

Zitat von Rollo62 (Beitrag 1467192)

Was genau meinst Du mit "mitkopiert" ?

Ist vorher Padding drin, hinterher nicht ?

Angenommen wir haben zwei Records

Delphi-Quellcode:

myRecordA, myRecordB: TMyRecord

mit der Definition

Delphi-Quellcode:

TMyRecord = record
  someByte: Byte;
  someInteger: Integer
end;

Und sagen wir myRecordA liegt beispielsweise so im Speicher:

Code:

  Byte #   Wert   Gehört zu    

  0        42     someByte     
  1        FF     (Padding)    
  2        FF     (Padding)    
  3        FF     (Padding)    
  4        00     someInteger  
  5        00     someInteger  
  6        00     someInteger  
  7        00     someInteger

Dann wurden früher ™ bei einer Zuweisung

Delphi-Quellcode:

myRecordB := myRecordA

nur die Bytes 0 und 4-7 in myRecordB gesetzt. Jetzt sind es alle.

Zitat:

Zitat von jaenicke (Beitrag 1467233)

Wenn sie in irgendeiner Version einmal nicht mit kopiert wurden, war das ein Bug.

Tatsächlich? Ich war die letzten Jahre auf 10.0 Seattle, und da wurden die Padding-Bytes bei einer Zuweisung definitiv nicht mitkopiert. Zu anderen Versionen kann ich nichts sagen. Ist ja auch eigentlich eine gute Sache dass es (jetzt) so ist.

[jaenicke]

Zitat:

Zitat von Der schöne Günther (Beitrag 1467247)

Zitat:

Zitat von jaenicke (Beitrag 1467233)

Wenn sie in irgendeiner Version einmal nicht mit kopiert wurden, war das ein Bug.

Tatsächlich? Ich war die letzten Jahre auf 10.0 Seattle, und da wurden die Padding-Bytes bei einer Zuweisung definitiv nicht mitkopiert. Zu anderen Versionen kann ich nichts sagen. Ist ja auch eigentlich eine gute Sache dass es (jetzt) so ist.

Ich habe nun in einer VM Delphi 10.0 ausprobiert. Auch da werden alle Bytes kopiert.

Beispielcode:

Delphi-Quellcode:

var
  test: PByte;
begin
  a.someByte := 1;
  a.someInteger := 1;
  test := @a.someByte;
  Inc(test);
  test^ := 42;
  b := a;
  test := @b.someByte;
  Inc(test);
  ShowMessage(IntToStr(test^));

Egal ob lokale Variablen oder globale Variablen, es kommt immer 42 heraus...

[Der schöne Günther]

Tut mir leid für den vielen Aufwand den ich verursacht habe. Das hätte sich vermeiden lassen wenn ich erst einmal geschaut hätte was an meinen Tests genau fehlgeschlagen ist. Dann hätte ich auch nicht unsinnige Schlüsse gezogen wie dass bei einer Zuweisung das Padding nicht mitkopiert werden würde.

Um genau zu sein ging es um Padding-Bytes am Schluss eines Records. Beispiel:

Delphi-Quellcode:

TPaddingAtEnd = record
  a:   Integer;
  b:   Byte;
end;

Hier war unter 10.4 das Padding hinten immer 0xFF und in den Tests wurde dann das Padding bei Record A auf 0xFF gesetzt und erwartet dass die Bytes ungleich waren mit denen von Record B. In 10.0 scheint das Padding hinten allerdings wie erwartet zufällig zu sein.

Für die ganz interessierten:

Delphi-Quellcode:

paddingAtEnd1.a := 10;
paddingAtEnd1.b := 99;
paddingAtEnd2 := paddingAtEnd1;
TRecordHelper.FillPaddingBytes(paddingAtEnd1, $FF);
CheckFalse( isBytewiseEqual(paddingAtEnd1, paddingAtEnd2) );

wobei

Delphi-Quellcode:

function TestRecordHelper.isBytewiseEqual<T>(const a, b: T): Boolean;
var
   comparer: IEqualityComparer<T>;
begin
   comparer := TEqualityComparer<T>.Default();
   Result := comparer.Equals(a, b);
end;

Das

Delphi-Quellcode:

CheckFalse(..)

schlug jetzt in 10.4 fehl da die beiden

Delphi-Quellcode:

paddingAtEnd

-Records schon von Anfang an am Schluss FFs hatten. Ich habe das Muster in den Tests jetzt gegen 0xAA, 0xBB usw getauscht und die Welt scheint wieder in Ordnung zu sein.

[jaenicke]

Ich hatte dort auch schlicht angeschaut was genau bei der Zuweisung im Speicher passiert, auch bei einem größeren Record:
Anhang 52678
Anhang 52679
Dort kann man sehr gut sehen, dass die 42=$2A mitkopiert wird und auch warum (zweimal mov auf 4 Byte).

[himitsu]

Hier wird direkt ein MOVE reinoptiermiert, da der Record klein ist und keine "schlimmen" Typen ethält.

Nimm für den Test auch mal einen String, Interface, Variant oder DynArray mit in den Record auf,
damit die CopyFunktionen aus System benutzt werden. (CopyRecord, bzw. CopyArray mit Länge 1)

[Der schöne Günther]

Ja, hier war wieder ein einfaches Weltbild am Werk, gemanagte Typen kommen in den Tests gar nicht vor. Danke! 👍