Records

[Edelfix]

Hallo,

letzte Zeit bemerke ich immer öfter das Records nicht korrekt initialisiert sind.
In unserem gigantischem Projekt sind Records eigentlich nie initialisiert. Deswegen kommt es immer wieder vor das unsere Kunden ein Fehler melden der bei uns aber nicht auftritt. Oder ein Fehler nur auf einem von zehn identischen Arbeitsplätzen auftritt. Ich habe das Gefühl das es häufiger geworden ist seit wir auf 64 Bit umgestellt haben.
Aktuell suche ich stunden lang nach genau dieser Stelle und initialisiere diesen einen Record.

Wie macht ihr das? Gibt es da eine Lösung die mir nicht bekannt ist?

Beispiel:

Delphi-Quellcode:

unit Unit1;

interface

type
  TRQRec = record
    isActiv: Boolean;
  end;

implementation

procedure Test1;
var
  RQRec: TRQRec;
begin
  //RQRec := Default(TRQRec); // zur Sicherheit initialisieren
  if RQRec.isActiv then // es ist manchmal true
  begin
    // do amasing things
  end;
end;

end.

[jaenicke]

Records werden dort durch Delphi nicht automatisch initialisiert. Die Werte sind bis zum Setzen eines Wertes pseudo-zufällig.

Anders sieht es bei referenzgezählten Felder in einem Record aus. Die werden initialisiert.

[Uwe Raabe]

Zitat:

Zitat von Edelfix (Beitrag 1528940)

In unserem gigantischem Projekt sind Records eigentlich nie initialisiert.

Meinst du damit, man geht einfach davon aus, dass Record-Felder automatisch genau so initialisiert werden wie Felder in Klassen? Also das Boolean immer False und Integer immer 0 sind? Dann wäre das allerdings grob fahrlässig und ebenso verwunderlich, dass es nicht schon früher zu solchen Problemen gekommen ist.

Zitat:

Zitat von Edelfix (Beitrag 1528940)

Wie macht ihr das? Gibt es da eine Lösung die mir nicht bekannt ist?

Eine von mir gern genutzte Alternative sind Konstruktoren, denen ich gleich ein paar Feldwerte als Parameter mitgeben kann.

Delphi-Quellcode:

type
  TRQRec = record
    isActiv: Boolean;
  public
    constructor Create(AisActiv: Boolean);
  end;

constructor TRQRec.Create(AisActiv: Boolean);
begin
  isActiv := AisActiv;
end;

procedure Test1;
var
  RQRec: TRQRec;
begin
  RQRec := TRQRec.Create(False);
  if RQRec.isActiv then
  begin
    // do amazing things
  end;
end;

Die mit neueren Delphi-Versionen verfügbaren Managed Records bieten da noch weitere Möglichkeiten:

Delphi-Quellcode:

type
  TRQRec = record
    isActiv: Boolean;
  public
    class operator Initialize(out Dest: TRQRec);
  end;

class operator TRQRec.Initialize(out Dest: TRQRec);
begin
  Dest.isActiv := False;
end;

procedure Test1;
var
  RQRec: TRQRec;
begin
  if RQRec.isActiv then // ist immer False
  begin
    // do amazing things
  end;
end;

[Der schöne Günther]

Zitat:

Zitat von Uwe Raabe (Beitrag 1528943)

Dann wäre das allerdings grob fahrlässig und ebenso verwunderlich, dass es nicht schon früher zu solchen Problemen gekommen ist.

Kann man einem da wirklich einen großen Vorwurf draus machen wenn der Compiler noch nicht einmal vor so etwas warnen kann?

[Edelfix]

Ich bin kein gelernter Delphi Programmierer. Versuche mir alles selbst bei zu bringen.

Haptsächlich versuche ich durch bestehenden Code zu lernen. Es wird aber schwieriger wenn meine Vorgänger mir keinen korekten Code überlassen haben.

Sehe ich das richtig das "Records" hauptsächlich oder ausschließlich ein Delphi Ding sind?

Auf jeden Fall schwinden die Vorteile eines Records beim Vergleich: Record vs. Class

Die einzige Zeile die ich einsparre ist die Freigabe des Records.

[Der schöne Günther]

Zitat:

Zitat von Edelfix (Beitrag 1528945)

Sehe ich das richtig das "Records" hauptsächlich oder ausschließlich ein Delphi Ding sind?

Ich weiß nicht, mit welchen Sprachen du vergleichen möchtest. Java beispielsweise hat kein Gegenstück, die Delphi-Records sind aber praktisch 1:1 das, was in C oder C++ structs sind.

Klassen und Records haben beide legitime Anwendungsfälle, das eine ist nicht per se "besser" als das andere.

[Jasocul]

Zitat:

Zitat von Edelfix (Beitrag 1528945)

Die einzige Zeile die ich einsparre ist die Freigabe des Records.

Und auch das kann man sich sparen, wenn man interfaces korrekt nutzt.

Records sind bei mir nur noch selten im Einsatz. Zur Initialisierung benutze ich den Fällen meistens:

Delphi-Quellcode:

type
  TMyRec = Record
    ...
  end;

var
  MyRec : TMyRec;
begin
  MyRec := Default(TMyRec);
end;

[Frickler]

Ich habe in Records immer eine Methode "Init", die den Record genau so initialisiert, wie ich das jeweils gerne hätte:

Delphi-Quellcode:

type
  TMyRec = Record
    ...
    procedure Init;
  end;

procedure TMyRec.Init;
begin
  ...
end;

var
  MyRec : TMyRec;
begin
  MyRec.Init;
  ...
end;

P.S.: für "Managed Records" haben wir eine zu alte Delphi-Version.

[Uwe Raabe]

Zitat:

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

Kann man einem da wirklich einen großen Vorwurf draus machen wenn der Compiler noch nicht einmal vor so etwas warnen kann?

Meiner Meinung nach, ja. Es ist natürlich einfach, die Schuld an einem Programmfehler dem Compiler zu geben, der nicht clever genug ist, diesen zu entdecken. Vielleicht bin ich aber auch einfach nur zu altmodisch.

[jaenicke]

Das Problem ist dabei aber z.B., dass ein Record ja wiederum weitere strukturierte Typen enthalten kann. Dazu kommt dann mittlerweile, dass ein Record auch Initialisierungsroutinen haben kann, deren Funktion der Compiler nicht kennen kann.

Solche Intelligenz ist daher vorerst Wunschdenken. Möglich wäre so etwas nur, wenn man den gesamten Quelltext an eine KI verfüttert.

[Sinspin]

Eine Record-Variable/Feld die in einer Klasse enthalten ist, sollte mit Null initialisiert sein, so wie alle anderen Felder der Klasse auch. Aber in Methoden/Proceduren/Funktionen sind lokale Variablen egal welchen Typs nie initialisiert.

[himitsu]

Die Lösung nennt sich Custom Managed Records.
https://docwiki.embarcadero.com/RADS...anaged_Records

Delphi-Quellcode:

type
  TMyRecord = record
    Value: Integer;
    class operator Initialize(out Dest: TMyRecord);
  end;

class operator TMyRecord.Initialize(out Dest: TMyRecord);
begin
  Dest.Value := 10;
end;

[jaenicke]

Ja, in diesem Fall ist das sicher die einfachste Lösung, da man dafür nur die Records selbst anfassen muss, nicht aber deren Verwendung im Quelltext.

[TSchnuckenbock]

Ich hab' eben mal im Code geschaut, wie ich generell programmiere....meine Vermutung war, daß ich generell alle Variablen initialisiere. Und genauso ist es. Ich verlasse mich nirgends darauf, wie eine eventuell Vorbelegung aussehen könnte. (Ich habe wenigstens auf die Schnelle keinen Code gefunden, in dem es anders ist.)
Bei Klassen geschieht das im Kontruktor oder es gibt z.B. eine Methode "Init" oder sowas in der Art. Da werden dann alle Felder einer Klasse mit Default-Werten vorbelegt, Events kriegen z.B. nil zugewiesen.

Im alten Code, den ich übernommen habe, könnte es aber anders aussehen.

[himitsu]

Managed Typen sind immer initialisiert (außer jemand pfuscht mit Pointern rum und verwendet die falsche Methode, zum Reservieren des Speichers)

Globale Variablen und Thread-Variablen werden durch Windows immer initialisiert (standardmäßig mit 0),
außer es wurde für eine globale Variable ein Initialisierungs-Wert angegeben.
Genauer gesagt, liegen globale Varaiblen in eine Sektion (Speicherbereich) der EXE/DLL.

Objekt-Felder (die Variablen in Delphi-Objekten) sind ebenfalls immer mit 0 initialisiert.
siehe das FillChar in TObject.InitInstance

Lokale Variablen (also auf dem Stack) sind normal nicht initialisiert.
* Ausnahme sind Managed Typen
Result ist nicht initialisiert
* Ausnahme sind Managed Typen (nur sind sie nicht dort initialisiert, wo ihr es denkt :twisted:)
* neuerdings werden z.B. Boolean-Results mit False initialisiert, weil ständig zuviele Leute grob fahrlässig die Compiler-Warnungen nicht lesen.

[TSchnuckenbock]

Ach ja, die Compiler-Meldungen bzgl. eventuell nicht initialisierten Sachen, schaue ich mir an und behebe das.
Das hat unsere Software übigens merklich stabiler gemacht.

[Edelfix]

Währe es so nicht noch besser?

Delphi-Quellcode:

class operator TMyRecord.Initialize(out Dest: TMyRecord);
begin
  //Dest.Value := 10;
  Dest := Default(TMyRecord);
end;

Scheint aber nicht zu funktionieren.

[Phoenix]

Zitat:

Zitat von Uwe Raabe (Beitrag 1528956)

Zitat:

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

Kann man einem da wirklich einen großen Vorwurf draus machen wenn der Compiler noch nicht einmal vor so etwas warnen kann?

Meiner Meinung nach, ja. Es ist natürlich einfach, die Schuld an einem Programmfehler dem Compiler zu geben, der nicht clever genug ist, diesen zu entdecken. Vielleicht bin ich aber auch einfach nur zu altmodisch.

Bist Du. Sorry ;)

In C# z.B. sind alle Felder aller Typen (Structs, Records, Classes) immer automatisch mit ihren jeweiligen Default-Werten initialisiert.

Rust als unmanaged Sprache hat z.B. das Ownership-Konzept, mit dem das Memory Management komplett durch den Compiler abgesichert wird. Es ist dort schlicht nicht möglich, Code zu schreiben der Unfug mit fremden Speicher anstellt, Buffer overruns produziert oder zu Memory Leaks führt, da einem der Compiler hier extrem hart auf die Finger klopft.

Und das ist gut so.
Klar sollte man als Entwickler immer eine Ahnung haben von dem was man tut und grob von dem was auf der Hardware physikalisch passiert (also wo steht z.B. was im Speicher), aber das bedeutet nicht, dass das Tooling einen nicht so gut dabei unterstützen sollte wie es rechnerisch möglich ist.

Wenn der Compiler einem Stundenlanges(!) suchen(!) nach Problemstellen nicht abnimmt, obwohl es möglich wäre (z.B. ein Schalter, der Initialisierungs-Code für jeden Record generiert), dann ist das meiner Meinung nach ein massiver Grund, sich nach besserem Tooling umzusehen.

[Der schöne Günther]

Ich finde es zwar schon legitim, dass Delphi die Record-Felder nicht implizit initialisiert, ist ja eine Performance-Sache.

Aber überhaupt nichts zu sagen, wenn wirklich eindeutig ist, dass hier mit nicht initialisiertem Speicher gearbeitet wird, und einem keine Möglichkeit geben, solche Stellen nachträglich zu finden, das ist echt nicht mehr feierlich.

PS: Oh, von Rust brauchen wir echt nicht anfangen. Das ist wirklich eine ganz andere Liga, was der Compiler und Linter da einem teilweise erzählen. Mein Favorit bislang war noch "Hey, benenn doch deine Methode besser so und so um, weil dann wird klarer, dass du mit den Daten das und das tust".

[Phoenix]

Zitat:

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

Ich finde es zwar schon legitim, dass Delphi die Record-Felder nicht implizit initialisiert, ist ja eine Performance-Sache.

Korrekt. Das aber zusätzlich anzubieten, als Option irgendwo alà "Ich weiß, es ist langsamer, aber ist auch sicherer, also mach an" wäre trotzdem nice.

Oder eben allein schon der Check als Compiler Hint oder gar Warning: "Hey, hier arbeitest Du mit nicht initialisierten Werten!", die Du dann beachten kannst oder aber im Stil von "Ich bin ein Software-Ingenieur, ich weiß, was ich tue", an der Stelle bewusst deaktivieren kannst, das wäre auch nett. Und ehrlich gesagt ist sowas inzwischen ja auch State-of-the-art.

So gern ich Pascal als Sprache immer noch lese - das sind so Dinge die mich einfach ganz krass davon abhalten, mir das wieder anzutun.
Aktuell bin ich mit TypeScript, C# und Python unterwegs, und je mehr linting und Compiler Support dort kommt, desto genialer finde ich das. Und desto effizienter werde ich mit der Zeit auch, weil ich, wenn ich einen Fehler mache, direkt vom Werkzeug darauf hingewiesen werde. Dann kann ich gucken was (und warum) ich das falsch gemacht habe, und lernen, wie ich das für die Zukunft vermeiden kann. Heißt im Umkehrschluss auch, ich produziere weniger Fehler und damit weniger Bugs, und spare mir damit schon von Afang an die Zeit, die ich sonst investieren müsste um die wieder zu fixen. :thumb:

[Kas Ob.]

Zitat:

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

Ich finde es zwar schon legitim, dass Delphi die Record-Felder nicht implizit initialisiert, ist ja eine Performance-Sache.

Can't agree more, i am fan of performance.

Zitat:

Zitat von Phoenix (Beitrag 1529113)

Zitat:

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

Ich finde es zwar schon legitim, dass Delphi die Record-Felder nicht implizit initialisiert, ist ja eine Performance-Sache.

Korrekt. Das aber zusätzlich anzubieten, als Option irgendwo alà "Ich weiß, es ist langsamer, aber ist auch sicherer, also mach an" wäre trotzdem nice.

Oder eben allein schon der Check als Compiler Hint oder gar Warning: "Hey, hier arbeitest Du mit nicht initialisierten Werten!", die Du dann beachten kannst oder aber im Stil von "Ich bin ein Software-Ingenieur, ich weiß, was ich tue", an der Stelle bewusst deaktivieren kannst, das wäre auch nett. Und ehrlich gesagt ist sowas inzwischen ja auch State-of-the-art.

Can't agree more, i am fan of more concrete and double checked code by the compiler and me, also with short and beautiful readable code, State-of-the-art is progress and always helpful.

Where is the problem, it is in taking the whole thing in one way, one direction, and denying other approaches, i am always was (and still) with more tools and options to work and use and realize what in my head.

Is there a way to have both without breaking backward compatibility, yes there is, but it needs open minds, sorry for the last phrase, because i already suggest similar or the same thing in other forum, and no one commented or did they, i can't remember.

Anyway, how about adding new directive or modifier for the variables in the var section and for the inline variables, something like

Code:

Procedure Test;
var
  MyRec: TMyRecord; Init;

and that it, also we can have a directive to tell the compiler to handle every record forward in this unit to Init to default, here comes simple initialization like filling with 0 or calling TMyRecord.Init;

Another example , which i really wish we had in Pascal/Delphi:

Code:

procedure CompareAndAddList(TargetList, SrcList1, SrcList2 : TStringList);
begin
......  // irrelevant 
end;

Procedure Test;
var
  List1, List2, List3 :TStringList; Auto;
begin
  List1.LoadFromFile....
  List2.GetDataFromSomewhere....
  CompareAndAddList(List1, List2, List3);
end;

No .Create, No .Free and definitely no that ugly nested try..finally, the compiler will insert the try..finally and call the constructor and destructor for each class, and we left with concrete will defined code, error free, and beautiful very beautiful and readable code, not breaking any thing.
In my opinion %99 of try..finally is just for calling Free, well some prefer here unnecessary FreeAndNil, but also doable.


are these approaches viable ? , yes they are since the compiler does in fact insert try..finally automatically for managed types, then why it can't add it for any type, on other hand for non managed types, compiler as i understand has inline variables now, so this line "var i := 0 ;", well how is that hard to handle the variables in var sections as inline and but insert them after "begin"
So technically it is there, just need to connect the dots, it is happening with all the VCL components, they are created and free without your code interaction, so have a public, private or protected var as TMyClass in Parent class declared as " CL: TMyClass; auto;" and the compiler will add create and free call in the parent constructor and destructor, how this is far away from using a string in that parent class ?!!

Hope someone will read this and request such thing, so Embarcadero after finishing their cosmic ships (eg. LSP so we can live on Mars happily ever after), will have time to make some progress on the IDE, compiler, and may be the Lnaguage in this case.

Sorry for ranting, and sorry more if this away from topic.

[Edelfix]

Wie ist es mit so einer Lösung? Spricht irgend etwas dagegen?

Delphi-Quellcode:

class operator TMyRecord.Initialize(out Dest: TMyRecord);
var
  LContext: TRttiContext;  // Uses System.Rtti
  LType: TRttiType;
  LRecord: TRttiRecordType;
  LField: TRttiField;
begin
  LContext := TRttiContext.Create;
  try
    LType := LContext.GetType(TypeInfo(TMyRecord));
    if LType.IsRecord then
    begin
      LRecord := LType.AsRecord;
      //--
      for LField in LRecord.GetFields do
      begin
        if (LField.FieldType.TypeKind=tkEnumeration) then
        begin
          if LField.FieldType.Handle = TypeInfo(Boolean) then
            LField.SetValue(@Dest, false)
        end else
        if (LField.FieldType.TypeKind=tkUString) then
          LField.SetValue(@Dest, '')
        else
        if (LField.FieldType.TypeKind=tkInteger) then
          LField.SetValue(@Dest, 0)
        else
        if (LField.FieldType.TypeKind=tkFloat) then
          LField.SetValue(@Dest, 0);
      end;
    end;
  finally
   LContext.Free;
  end;
  //Dest.Value := 10;
  //Dest := Default(TMyRecord);
end;

[dummzeuch]

Zitat:

Zitat von Edelfix (Beitrag 1529127)

Wie ist es mit so einer Lösung? Spricht irgend etwas dagegen?

Delphi-Quellcode:

        if (LField.FieldType.TypeKind=tkUString) then
          LField.SetValue(@Dest, '')
        else

Stringtypen werden bereits automatisch mit einem Leerstring initialisiert.

Ansonsten spricht nichts dagegen, allerdings fehlen viele weitere Datentypen, insbesondere Unter-Records.

Und es funktioniert natürlich nur, wenn man die Erweiterte RTTI nicht abschaltet (wenn ich mich recht erinnere, ist das ein Compilerschalter).

[Mavarik]

Zitat:

Zitat von Edelfix (Beitrag 1528940)

Wie macht ihr das?

Beispiel Initialisierung:

Delphi-Quellcode:

unit Unit1;

interface

type
  TRQRec = record
    isActiv: Boolean;
  end;

implementation

procedure Test1;
var
  RQRec: TRQRec;
begin
  Fillchar(RQRec,Sizeof(RQRec),#0);

  if RQRec.isActiv then // es ist manchmal true
  begin
    // do amasing things
  end;
end;

end.

Beispiel Record wird an eine Procedure übergeben und ich will testen ob es initialisiert wurde:

Delphi-Quellcode:

unit Unit1;

interface

type
  TRQRec = record
    Data : integer;
    isActiv: String;
    Constructor Create(aData : Integer);
  end;

implementation

procedure Test1;
var
  RQRec: TRQRec;
begin
  if RQRec.isActiv = '' then
    RQRec := TQRRec.Create(42);
end;

Constructor TRQRec.Create(aData : Integer);
begin
  Data := aData;
  isActiv := '*';
end;

end.

[mytbo]

Zitat:

Zitat von Kas Ob. (Beitrag 1529118)

Code:

Procedure Test;
var
  MyRec: TMyRecord; Init;

and that it, also we can have a directive to tell the compiler to handle every record forward in this unit to Init to default, here comes simple initialization like filling with 0 or calling TMyRecord.Init;

In newer Delphi versions you can already do a lot. Defined with a few lines and clearer for me:

Delphi-Quellcode:

type
  TTestRec = record
    Name: String;
    Count: Integer;
    Address: array of record
      Street: String;
      ZIPCode: Integer;
    end;
  public
    function AddAddress(const pmcStreet: String; pmZIPCode: Integer): Integer;
    procedure Init;
    procedure Clear;
  end;

function TTestRec.AddAddress(const pmcStreet: String; pmZIPCode: Integer): Integer;
begin
  Result := Length(Address);
  SetLength(Address, Result + 1);
  with Address[Result] do
  begin
    Street := pmcStreet;
    ZIPCode := pmZIPCode;
  end;
end;

procedure TTestRec.Init;
begin
  FillChar(Self, SizeOf(Self), 0);
end;

procedure TTestRec.Clear;
begin
  Finalize(Self);
  Init;
end;

Or functions are outsourced to a record helper. Use it like this:

Delphi-Quellcode:

var
  rec: TTestRec;
begin
  rec.Init;
  ShowMessage(rec.Count.ToString);
  rec.AddAddress('Paddington', 123);
  ShowMessage(rec.Address[0].ZIPCode.ToString);
  rec.Clear;
  ShowMessage(Length(rec.Address).ToString);

Zitat:

Zitat von Kas Ob.

... No .Free and definitely no that ugly nested try..finally, ...

There is something similar (not the same) in mORMot. Used very carefully, it can be helpful:

Delphi-Quellcode:

var
  sList1, sList2: TStringList;
  oList1, oList2: TObjectList;
begin
  with TAutoFree.One(sList1, TStringList.Create) do
  begin
    sList1.Add('Test');
    Another(oList1, TObjectList.Create);
    oList1.Add(TObject.Create);
  end;

  with TAutoFree.Several([
    @sList2, TStringList.Create,
    @oList2, TObjectList.Create]) do
  begin
    sList2.Add('Test');
    oList2.Add(TObject.Create);
  end;
end;

I would like to see the NameOf function much more urgently. Although it is highly voted, we hear nothing about its realization.

With best regards
Thomas

[himitsu]

Zitat:

Zitat von Edelfix (Beitrag 1529102)

Delphi-Quellcode:

class operator TMyRecord.Initialize(out Dest: TMyRecord);
begin
  //Dest.Value := 10;
  Dest := Default(TMyRecord);
end;

Ich hätte hier eine Endlosschleife erwartet. :stupid:

Default() müsste doch den Record initialisieren, also auch den ClassConstructor aufrufen.

[Kas Ob.]

Zitat:

Zitat von mytbo (Beitrag 1529142)

Zitat:

Zitat von Kas Ob. (Beitrag 1529118)

Code:

Procedure Test;
var
  MyRec: TMyRecord; Init;

and that it, also we can have a directive to tell the compiler to handle every record forward in this unit to Init to default, here comes simple initialization like filling with 0 or calling TMyRecord.Init;

In newer Delphi versions you can already do a lot. Defined with a few lines and clearer for me:

Delphi-Quellcode:

type
  TTestRec = record
    Name: String;
    Count: Integer;
    Address: array of record
      Street: String;
      ZIPCode: Integer;
    end;
  public
    function AddAddress(const pmcStreet: String; pmZIPCode: Integer): Integer;
    procedure Init;
    procedure Clear;
  end;

function TTestRec.AddAddress(const pmcStreet: String; pmZIPCode: Integer): Integer;
begin
  Result := Length(Address);
  SetLength(Address, Result + 1);
  with Address[Result] do
  begin
    Street := pmcStreet;
    ZIPCode := pmZIPCode;
  end;
end;

procedure TTestRec.Init;
begin
  FillChar(Self, SizeOf(Self), 0);
end;

procedure TTestRec.Clear;
begin
  Finalize(Self);
  Init;
end;

Or functions are outsourced to a record helper. Use it like this:

Delphi-Quellcode:

var
  rec: TTestRec;
begin
  rec.Init;
  ShowMessage(rec.Count.ToString);
  rec.AddAddress('Paddington', 123);
  ShowMessage(rec.Address[0].ZIPCode.ToString);
  rec.Clear;
  ShowMessage(Length(rec.Address).ToString);

Zitat:

Zitat von Kas Ob.

... No .Free and definitely no that ugly nested try..finally, ...

There is something similar (not the same) in mORMot. Used very carefully, it can be helpful:

Delphi-Quellcode:

var
  sList1, sList2: TStringList;
  oList1, oList2: TObjectList;
begin
  with TAutoFree.One(sList1, TStringList.Create) do
  begin
    sList1.Add('Test');
    Another(oList1, TObjectList.Create);
    oList1.Add(TObject.Create);
  end;

  with TAutoFree.Several([
    @sList2, TStringList.Create,
    @oList2, TObjectList.Create]) do
  begin
    sList2.Add('Test');
    oList2.Add(TObject.Create);
  end;
end;

I would like to see the NameOf function much more urgently. Although it is highly voted, we hear nothing about its realization.

With best regards
Thomas

Nice points.

I am familiar with the above, so let me clear more on that.

1) Yes adding Init as record constructor to each and every record is doable, but, do i really want to add such code every where, or revert to helpers and lose the ability to use another helper in more constructive way for such small functionality, anyway it is not about record per se, see the suggested Init could be with anything like signed or unsigned integers, counters, index, float, chars, Booleans, short strings, array [fixedsize] of (bytes, chars, ), .... etc... and most critical my own types, simply for every type that can have value, if 0 is possible value then fill it, otherwise use the smallest value or the first defined like these, they could have default value and i don't need to worry about

Code:

type 
  Suit = (Club, Diamond, Heart, Spade); 
  Size = (Small = 5, Medium = 10, Large = Small + Medium); 
  SomeNumbers = -128..127;
  Caps = 'A'..'Z';
  SomeNum: 1..500;

2) As for TAutoFree from mORMot, i did my share of those as i have my own solution, but still it is not elegant as if done by the compiler.. clear, beautiful and short, also my biggest problem where i count up to 1000 before decide to import and insert an open source library in my project for such small addition, such approach still and will stay error prone and the compiler will not help or warn about memory leak before hand, while such Auto functionality, i can rest assured it is done right.

3) NameOf and IndexOf and TypeOf .. OffsetOf, all of these worth adding not only for Pascal syntax and Delphi RTL but to the assembler too, also the ability to access VMT in easier and way with the ability to distinguish overridden method which will be great too, the point here, these methods are dangerous and defeat of secure coding by override the flow of code dictated by the language itself and curated by compiler, but we have crippled compiler and outdated language, so if Embarcadero can't/wouldn't revise and progress on the front, then we as users should have tools to overcome these ancient obstacles.