Lokalen Record initialisieren

[Der schöne Günther]

Lokale Variable in einer Prozedur, es ist ein Record. Da es kein 'managed' Typ wie ein String ist, stehen anfangs ja noch die wildestens Dinge in den Feldern. Ich sehe mittlerweile schon vier verschiedene Möglichkeiten, das Ding zu initialisieren:

Delphi-Quellcode:

procedure TForm2.FormCreate(Sender: TObject);
var
   startInfo: TStartupInfo;
   someRecord: TSomeRecord;
begin

   ZeroMemory(@someRecord, SizeOf(someRecord));    // (1)
   someRecord := Default(TSomeRecord);             // (2)
   FillChar(someRecord, SizeOf(someRecord), 0);    // (3)
   someRecord := TSomeRecord.Create(True);         // (4)

   print(someRecord.someInt);
   print(someRecord.someByte);

end;

mit

Delphi-Quellcode:

TSomeRecord = record
   someInt: Integer;
   someByte: Byte;
   constructor Create(const useDefault: Boolean);
end;

constructor TSomeRecord.Create(const useDefault: Boolean);
begin
   if useDefault then
      self := Default(TSomeRecord); // Methoden (1)-(3) oder komplett von Hand
end;

Delphi-Quellcode:

ZeroMemory

ist aus

Delphi-Quellcode:

Winapi.Windows

,

Delphi-Quellcode:

FillChar

aus

Delphi-Quellcode:

System

. Zu

Delphi-Quellcode:

Default

finde ich nichts.


Abgesehen davon, dass ZeroMemory eine Windows-Funktion ist, was sollte man eigentlich im Normalfall nehmen? Ich bin im Debugger nicht detailliert durchgesteppt, aber so eine große Auswahl macht einem ja geradezu Angst...

[TiGü]

Da hab ich auch schon ein paar Mal überlegt und bin bei Option 3 geblieben.

[himitsu]

Am Sichersten ist man wohl mit Option 2 und 4.

Schade daß man keine parameterlosen Record-Konstructoren erstellen darft. (Nja, dank eines defaultparameters könnte man da eventuell tricksen).

Man könnte emba ja mal fragen, ob die einem einen lokalen Compilerschalter geben, mit dem man sagen kann daß er bei den "nachfolgenden" Prozeduren die lokalen variablen mit 0 initialisieren soll. Oder einen Parameter, welchen man bei den Variablendeklarationen angibt. (quasi wie das absolute oder bei den Properties das default)

[Stevie]

Ich würde Methode 2 benutzen. Im Gegensatz zu den anderen Möglichkeiten ist die nämlich auch safe, wenn man möglicherweise managed Felder im Record hat und diese unter Umständen schon irgendwie zwischen begin und dem Aufruf gesetzt wurden. Ein ZeroMemory (welches auch nur FillChar aufruft) schreibt nämlich einfach stumpf Nullen drüber. Das funktioniert für managed Felder also nur, wenn diese sowieso schon genullt sind.

Siehe dieser SO Eintrag (und die verlinkte Antwort von Allen Bauer)

Mehr Informationen auch noch hier bzgl der Performance von Default() (in der Antwort von Arnaud): http://stackoverflow.com/questions/1...delphi-at-once

Zitat:

Zitat von himitsu (Beitrag 1235547)

(Nja, dank eines defaultparameters könnte man da eventuell tricksen).

Nö :(

Code:

E2471 Possibly parameterless constructors not allowed on record types

[Uwe Raabe]

Zitat:

Zitat von Stevie (Beitrag 1235550)

Zitat:

Zitat von himitsu (Beitrag 1235547)

(Nja, dank eines defaultparameters könnte man da eventuell tricksen).

Nö :(

Code:

E2471 Possibly parameterless constructors not allowed on record types

Aber so ginge es:

Delphi-Quellcode:

  TSomeRecord = record
    class function Create: TSomeRecord; static;
  end;

[himitsu]

Ach ja:
InitializeRecord
FinalizeRecord

Einige der geheimen Funktionen, wie das auch UniqueString.
Delphi nutzt diese Funktionen selber, um die managed Typen in Recordvariablen zu behandeln und auch bei Objektvariablen oder bei New und Dispose.

[Stevie]

Zitat:

Zitat von Uwe Raabe (Beitrag 1235554)

Zitat:

Zitat von Stevie (Beitrag 1235550)

Zitat:

Zitat von himitsu (Beitrag 1235547)

(Nja, dank eines defaultparameters könnte man da eventuell tricksen).

Nö :(

Code:

E2471 Possibly parameterless constructors not allowed on record types

Aber so ginge es:

Delphi-Quellcode:

  TSomeRecord = record
    class function Create: TSomeRecord; static;
  end;

Schon klar.
Aber in diesem Fall schreibt man extra Code, um etwas langsamer zu lösen, als es mit weniger Code vom Compiler erledigt wird. ;)

[himitsu]

Und vergiss nicht das

Delphi-Quellcode:

with Result do begin


end;

um den Code in der "falschen" Create-Funktion, damit der enthaltene Code dann genauso geschrieben werden kann, als stünde er in einem richtigen Constructor.

[Der schöne Günther]

Zitat:

Zitat von himitsu (Beitrag 1235556)

Einige der geheimen Funktionen, wie das auch UniqueString.

Ähnlich wie das Default: Die sind wohl wirklich so geheim dass es keine offizielle Doku dazu gibt, oder? Gerade das Default hätte mich jetzt interessiert, aber ich stelle mich zu dumm an, irgendwas zu finden.

[himitsu]

Das Default(T) stammt vermutlich von den Generics. (steht da bestimmt irgendwo unauffällig in der Doku mit drin)

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1235556)

Ach ja:
InitializeRecord
FinalizeRecord

Einige der geheimen Funktionen, wie das auch UniqueString.

Und wie soll man die hier verwenden? Mein Compiler kennt die jedenfalls nicht.

Das interne InitializeRecord wird übrigens automatisch vom Compiler aufgerufen, wenn die lokale Record-Variable z.B. einen String enthält. Leider wird damit aber ein ebenso vorhandenes Integer-Feld nicht initialisiert.

Delphi-Quellcode:

type
  TSomeRecord = record
    Data: Integer;
    Name: string;
  end;
var
  someRecord: TSomeRecord;
begin
  Caption := Format('"%s"(%d)', [someRecord.Name, someRecord.Data]);
end;

[sx2008]

Also von der Variante (4) würde ich ganz absehen, da es so aussieht als ob ein Objekt einer Klasse auf dem Heap erzeugt wird.
In Wirklichkeit wird ein Record auf dem Stack erzeugt (bzw der Speicher für den Record liegt auf dem Stack und der Record wird initialisiert).
Derjenige der den Code in Zukunft warten muss wird hinters Licht geführt und das ist nicht gut.

Ich muss sowieso immer wieder feststellen dass Delphiprogrammierer in vielen Fällen an einem Record festhalten wo eigentlich eine Klasse angebracht wäre.

[Stevie]

Zitat:

Zitat von Uwe Raabe (Beitrag 1235568)

Zitat:

Zitat von himitsu (Beitrag 1235556)

Ach ja:
InitializeRecord
FinalizeRecord

Einige der geheimen Funktionen, wie das auch UniqueString.

Und wie soll man die hier verwenden? Mein Compiler kennt die jedenfalls nicht.

Nur Initialize/Finalize. Das ruft InitializeRecord/FinalizeRecord intern auf. Oder du bastelst dir was (so kommt man übrigens an alle sonst unzugänglichen Routinen) ;)

Delphi-Quellcode:

function InitializeRecord(P: Pointer; TypeInfo: Pointer): Pointer;
asm
  jmp System.@InitializeRecord
end;

[himitsu]

Zitat:

Zitat von sx2008 (Beitrag 1235569)

Also von der Variante (4) würde ich ganz absehen, da es so aussieht als ob ein Objekt einer Klasse auf dem Heap erzeugt wird.
In Wirklichkeit wird ein Record auf dem Stack erzeugt (bzw der Speicher für den Record liegt auf dem Stack und der Record wird initialisiert).

Das Stimmt nur indirekt.

(beim Constructor weiß ich es jetzt nicht genau)
Aber bei der class-funktion wird das Result als Out-Parameter übergeben. (wenn der Record größer als 8 Byte ist oder Managed-Typen enthält, ansonsten wird er wie ein Int64 behandelt)
Es wird dürfte also direkt in den Speicherbereich der Variable geschrieben werden. :gruebel:

@Uwe: Entschuldigung.
Das liegt daran, daß die Funktionen in der System und SysInit oftmals anders heißen. Im Quellcode heißen die so. Im Delphi/Pascal-Code werden die anders benannt, beim Aufruf, und im ASM heißen die manchmal nochmals anders.
Einige Funktion lassen sich auch nur von ASM aus aufrufen, da sie im Pascal garnicht verlinkt sind. usw.

Finalize Initialize
FinalizeArray InitializeArray (Count=1 = Record)

Beispiel (siehe Stevie):
System.pas = _InitializeRecord
Pascal = Initialize
Assembler = @InitializeRecord

[Bjoerk]

Zitat:

Zitat von Uwe Raabe (Beitrag 1235554)

Aber so ginge es:

Delphi-Quellcode:

  TSomeRecord = record
    class function Create: TSomeRecord; static;
  end;

Fein. :thumb: Kann in einem Record eine procedure auch Free heißen, dann hätte man das Gegenstück zum Pseudoconstructor und könnte mäglichen belegten Speicher (z.B. dyn. arrays freigeben)?

[himitsu]

Kein Problem.

Im Prinzip kann man auch noch
eventuell einen Destructor schreiben (nur ohne das override)
sowie einen class constructor und class destructor für seine class var's (entspricht dem initialization- und finalization-Abschnitten)

[Mikkey]

Zitat:

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

Abgesehen davon, dass ZeroMemory eine Windows-Funktion ist, was sollte man eigentlich im Normalfall nehmen?

Selbst in C(++) kommt man nicht immer mit dem ZeroMemory (oder memset) aus. Wenn man die Kontrolle über die Definition hat, sollte man eine Record-Methode ("Init()", "Initialise()", "Reset()") schreiben, die die einzelnen Felder "wie es sich gehört" mit Standardwerten bestückt.

Den ZeroMemory habe ich bei solchen Records wie "LOGFONT" verwendet, weil darin halt gefühlte 100 nicht benötigte Einzelfelder vorkommen und (in C) das Ausnullen den gewünschten Effekt liefert.

[Namenloser]

Zitat:

Zitat von Bjoerk (Beitrag 1235574)

Kann in einem Record eine procedure auch Free heißen, dann hätte man das Gegenstück zum Pseudoconstructor und könnte mäglichen belegten Speicher (z.B. dyn. arrays freigeben)?

Auch bei TObject ist Free eine normale Prozedur – der eigentliche Destructor heißt Destroy, aber auch das ginge beim Record. Die Freigabe von dynamischen Arrays macht Delphi aber sowieso automatisch am Ende des Scopes, dafür braucht man keinen Destructor.

Aufpassen muss man höchstens, wenn man mit Pointern auf Records hantiert, in dem Fall muss man u.U. manuell Finalize aufzurufen.