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 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 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 von Der schöne Günther:

...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 von Der schöne Günther:

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 von Der schöne Günther:

... 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 von Der schöne Günther:

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 von Rollo62:

Was genau meinst Du mit "mitkopiert" ?

Ist vorher Padding drin, hinterher nicht ?

Angenommen wir haben zwei Records 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 myRecordB := myRecordA nur die Bytes 0 und 4-7 in myRecordB gesetzt. Jetzt sind es alle.

Zitat von jaenicke:

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.