record fillchar Speicherleck

[sx2008]

Zitat:

Zitat von baumina (Beitrag 1255936)

Ich hatte mich für einen globalen Record entschieden, da dieser alle wichtigen Daten meines aktuell gewählten Mantanten enthält

Hat denn dein Mandant keine Methoden wie z.B. Load(), Save()?
Oder vielleicht brauchst du irgendwann eine Methode die Länderkennzeichen, Postleitzahl und Ort in einem String liefert.
Warum also mit einem Record beginnen wenn doch eine Klasse einen Mehrwert bietet?

Und du kannst mir glauben - irgendwann kommst du an den Punkt an dem du merkst dass du mehrere Mandanten-Objekte brauchst.
Dann wirst du ärgern dass du an tausend Stellen auf einen globalen Record zugreifst.

[Dejan Vu]

[rethorische Frage]Wozu überhaupt noch Records?[/rethorische Frage]

[himitsu]

Records kann man in einem Zug in und aus einem Stream kopieren. (allerdings dürfen dann keine Pointer-Typen enthalten sein)

Records haben eine automatische Speicherverwaltung

Man zieht nicht einen ganz so großen Schwanz an Vererbungs unr RTTI-Zeugs mit.

Und man kann sowas wie die Operatoren nutzen, welches ohne eine automatische Speicherverwalung nunmal nicht geht. (nja, bei Interfaces und bei Objekten mit ARC ginge es dennoch, wenn/falls es implementiert ist und wenn die endlich mal den seit Jahren von mir gewünschen Copy-Operator implementieren)

[Sir Rufo]

Generell ist das Verwenden von globalen Variablen zu vermeiden, vor allem, weil es eine einfache Möglichkeit gibt, diese zu schützen.

Delphi-Quellcode:

interface

function GlobValue : MyRecord;
procedure SetGlobValue( const Value : MyRecord );

implementation

var
  _GlobValue;

function GlobValue : MyRecord;
begin
  Result := _GlobValue;
end;

procedure SetGlobValue( const Value : MyRecord );
begin
  // prüfen, ob die Änderung erlaubt ist
  _GlobValue := Value;
  // Benachrichtigung über die Änderung
end;

Sinnvoll ist es auch den Record immutable (unveränderlich) zu gestalten und die Erzeugung des Wertes über einen Konstruktor zu regeln:

Delphi-Quellcode:

MyRecord = record
private
  FS1 : string;
  FS2 : string;
public
  constructor Create( const S1, S2 : string );
  property S1 : string read FS1;
  property S2 : string read FS2;
end;

constructor MyRecord.Create( const S1, S2 : string );
begin
  // Validierung
  FS1 := S1;
  FS2 := S2;
end;

Im Konstruktor kann jetzt auf Plausibilität geprüft werden und bei unsinnigen Werten wirft man eine Exception.

Mit diesen einfachen Mitteln wird es unmöglich gemacht, dass unbemerkt Änderungen gemacht werden oder inkonsistente Daten vorliegen.

[Bjoerk]

Zitat:

Zitat von Dejan Vu (Beitrag 1256212)

[rethorische Frage]Wozu überhaupt noch Records?[/rethorische Frage]

Records eignen sich gut als Result von functions. Man kann auch einfach A := B schreiben (egal wie tief der Record verschachtelt ist) falls der Record nur aus Wertetypen und stat. Array besteht. Listen von Records sind allerdings fehleranfällig, z.B. verschwindet Items[Index].Clear im Nirwana (falls Items eine property ist).