How to properly free records that contain various types in Delphi at once?

Question

type
  TSomeRecord = Record
    field1: integer;
    field2: string;
    field3: boolean;
  End;
var
  SomeRecord: TSomeRecord;
  SomeRecAr: array of TSomeRecord;

This is the most basic example of what I have and since I want to reuse SomeRecord (with certain fields remaining empty, without freeing everything some fields would be carried over when I'm reusing SomeRecord, which is obviously undesired) I am looking for a way to free all of the fields at once. I've started out with string[255] and used ZeroMemory(), which was fine until it started leaking memory, that was because I switched to string. I still lack the knowledge to get why, but it appears to be related to it being dynamic. I am using dynamic arrays as well, so I assume that trying ZeroMemory() on anything dynamic would result in leaks. One day wasted figuring that out. I think I solved this by using Finalize() on SomeRecord or SomeRecAr before ZeroMemory(), but I'm not sure if this is the proper approach or just me being stupid.

So the question is: how to free everything at once? does some single procedure exist at all for this that I'm not aware of?

On a different note, alternatively I would be open to suggestions how to implement these records differently to begin with, so I don't need to make complicated attempts at freeing stuff. I've looked into creating records with New() and then getting rid of it Dispose(), but I have no idea what it means when a variable after a call to Dispose() is undefined, instead of nil. In addition, I don't know what's the difference between a variable of a certain type (SomeRecord: TSomeRecord) versus a variable pointing to a type (SomeRecord: ^TSomeRecord). I'm looking into the above issues at the moment, unless someone can explain it quickly, it might take some time.

Cohleen

Related: #14176698 – Brushoff

Related: #46764364 – Brushoff

Related: #5509894 – Brushoff

Answer 1

Assuming you have a Delphi version that supports implementing methods on a record, you could clear a record like this:

type
  TSomeRecord = record
    field1: integer;
    field2: string;
    field3: boolean;
    procedure Clear;
  end;

procedure TSomeRecord.Clear;
begin
  Self := Default(TSomeRecord);
end;

If your compiler doesn't support Default then you can do the same quite simply like this:

procedure TSomeRecord.Clear;
const
  Default: TSomeRecord=();
begin
  Self := Default;
end;

---

You might prefer to avoid mutating a value type in a method. In which case create a function that returns an empty record value, and use it with the assignment operator:

type
  TSomeRecord = record
    // fields go here
    class function Empty: TSomeRecord; static;
  end;

class function TSomeRecord.Empty: TSomeRecord;
begin
  Result := Default(TSomeRecord);
end;

....

Value := TSomeRecord.Empty;

---

As an aside, I cannot find any documentation reference for Default(TypeIdentifier). Does anyone know where it can be found?

---

As for the second part of your question, I see no reason not to continue using records, and allocating them using dynamic arrays. Attempting to manage the lifetime yourself is much more error prone.

Compunction

@NGLN I realise that the essence of this answer is what you originally wrote. I think it was an excellent answer. To my mind it's a shame you removed it. If you restored such an answer then I'd delete this and up-vote yours. But I think this question should have an answer along these lines. I'd rather it was yours since you were first. – Compunction

Agreed. No hard feelings, I'll keep mine as is now. – Lacquer

@Lacquer OK thanks for understanding and I've removed my downvote, that was harsh. – Compunction

I was about to ask the same, as a quick look in the help didn't produce anything about Default(). I do have XE2, so it most definitely supports methods in records. Default() however, I have no idea, I need to try this out. I do love that you can do EmptySomeRecord: TSomeRecord=(), I'm using that somewhere definitely in the future. – Cohleen

@Cohleen Default() I think is identical in effect to the constant declaration. – Compunction

@DavidHeffernan, everything works. Default() is supported and takes the cake. Love it. Now to hunt down some documentation. – Cohleen

Never seen any reference to Default() before. It's in Delphi XE as well and Delphi 2009 but not Delphi 2007. – Peder

@LU RD It's a construct much used with generics. My guess it came in 2009. – Compunction

Updated some other similar questions with a reference to this answer. See linked questions on this page. – Peder

This "default" record copy trick is just IMHO overcomplicated and slower than Finalize+FillChar. See my answer. – Nordrheinwestfalen

@ArnaudBouchez Are you for real? You think that the use of Default() is over-complicated?!! And your low-level memcpy code is the simple approach? – Compunction

@ArnaudBouchez Having looked at the code generated, it is clear that assigning Default() results in highly efficient code. You may like to reconsider your comment and the down-vote? – Compunction

@DavidHeffernan It was overcomplicated non about typing in the IDE, but for several reasons, due to the fact that it will allocate a default record, then finalize the destination record, then copy the default record into the destination record. Therefore it will be: 1. slower; 2. use more memory; 3. Write some code which is an assignment, i.e. a variable copy, whereas it is about initialization - that's why your "Clear" method does make sense. But IMHO it should not be implemented with a record copy, but with what the RTL others and do by itself: Finalize and Fill. – Nordrheinwestfalen

@Arnaud You should get your facts straight here. Look at the code generated by assigning Default(TSomeRecord). Also, I know you have a keen obsession with performance, but clarity of code for the human reader is more important to most people. – Compunction

@DavidHeffernan I just checked the code generated by Self := default(record). It does Finalize + inline fillchar using stosd. It is optimized (until you do not use "rep stosd"). So you are right, it is good code about speed. If only they may have added such a "Clear" method to records, compiler generated, just like in DWS, and not with this assignment syntax... – Nordrheinwestfalen

7 years later...still no obvious documentation on this. – Notarial

Answer 2

Don't make thinks overcomplicated!

Assigning a "default" record is just a loss of CPU power and memory.

When a record is declared within a TClass, it is filled with zero, so initialized. When it is allocated on stack, only reference counted variables are initialized: others kind of variable (like integer or double or booleans or enumerations) are in a random state (probably non zero). When it will be allocated on the heap, getmem will not initialize anything, allocmem will fill all content with zero, and new will initialize only reference-counted members (like on the stack initialization): in all cases, you should use either dispose, either finalize+freemem to release a heap-allocated record.

So about your exact question, your own assumption was right: to reset a record content after use, never use "fillchar" (or "zeromemory") without a previous "finalize". Here is the correct and fastest way:

Finalize(aRecord);
FillChar(aRecord,sizeof(aRecord),0);

Once again, it will be faster than assigning a default record. And in all case, if you use Finalize, even multiple times, it won't leak any memory - 100% money back warranty!

Edit: After looking at the code generated by aRecord := default(TRecordType), the code is well optimized: it is in fact a Finalize + bunch of stosd to emulate FillChar. So even if the syntax is a copy / assignement (:=), it is not implemented as a copy / assignment. My mistake here.

But I still do not like the fact that a := has to be used, where Embarcadero should have better used a record method like aRecord.Clear as syntax, just like DelphiWebScript's dynamic arrays. In fact, this := syntax is the same exact used by C#. Sounds like if Embacardero just mimics the C# syntax everywhere, without finding out that this is weird. What is the point if Delphi is just a follower, and not implement thinks "its way"? People will always prefer the original C# to its ancestor (Delphi has the same father).

Nordrheinwestfalen

Why a so proud "-1" without any comment? ;) – Nordrheinwestfalen

Your down-voter obviously changed their mind, but a downvote would be deserved here. First of all, performance is probably not the most important factor for the OP. But more importantly, your assertions here are not correct. aRecord := Default(TSomeRecord) is efficient. – Compunction

@DavidHeffernan Of course, it is not dead slow. But definitively Finalize + Copy will be slower than Finalize + FillChar. And an assignment is just confusing here. See my comment in your answer. Copy record is far from optimized in Delphi: it uses RTTI, and not compiler optimized code - see blog.synopse.info/post/2010/03/23/CopyRecord-faster-proposal – Nordrheinwestfalen

@DavidHeffernan I just checked the code generated by Self := default(record). It does Finalize + inline fillchar using stosd. It is optimized (until you do not use "rep stosd"). So you are right, it is good code about speed. If only the record copy (much more used) have been so much optimized. – Nordrheinwestfalen

Efficiency of code to clear a record only matter if that code is a hot spot in your app. It would seem unlikely for that to be so. – Compunction

In fact, in my simple benchmarks, Finalize/FillChar is slower than my suggestion. So, even though the issue of performance is probably irrelevant, your facts appear to be incorrect. You now have the opportunity to correct the misinformation by way of an edit to your answer. – Compunction

Interestingly, your code is the slowest of all 3 options on x64. No idea why. Not that the differences between any of the options appear significant to me. – Compunction

Much of the time will be spent in Finalize. FillChar uses the x87 registers, so may be slower on Wow64 than some stosd - but I'm quite sure it won't be slower with bigger records (which would be encoded by the compiler as rep stosd, which is slow opcode to start). I'll edit my answer. – Nordrheinwestfalen

Answer 3

The most simply solution I think of will be:

const
  EmptySomeRecord: TSomeRecord = ();
begin
  SomeRecord := EmptySomeRecord;

But to address all the remaining parts of your question, take these definitions:

type
  PSomeRecord = ^TSomeRecord;
  TSomeRecord = record
    Field1: Integer;
    Field2: String;
    Field3: Boolean;
  end;
  TSomeRecords = array of TSomeRecord;
  PSomeRecordList = ^TSomeRecordList;
  TSomeRecordList = array[0..MaxListSize] of TSomeRecord;    
const
  EmptySomeRecord: TSomeRecord = ();
  Count = 10;    
var
  SomeRecord: TSomeRecord;
  SomeRecords: TSomeRecords;
  I: Integer;
  P: PSomeRecord;
  List: PSomeRecordList;

procedure ClearSomeRecord(var ASomeRecord: TSomeRecord);
begin
  ASomeRecord.Field1 := 0;
  ASomeRecord.Field2 := '';
  ASomeRecord.Field3 := False;
end;

function NewSomeRecord: PSomeRecord;
begin
  New(Result);
  Result^.Field1 := 0;
  Result^.Field2 := '';
  Result^.Field3 := False;
end;

And then here some multiple examples on how to operate on them:

begin
  // Clearing a typed variable (1):
  SomeRecord := EmptySomeRecord;

  // Clearing a typed variable (2):
  ClearSomeRecord(SomeRecord);

  // Initializing and clearing a typed array variabele:
  SetLength(SomeRecords, Count);

  // Creating a pointer variable:
  New(P);

  // Clearing a pointer variable:
  P^.Field1 := 0;
  P^.Field2 := '';
  P^.Field3 := False;

  // Creating and clearing a pointer variable:
  P := NewSomeRecord;

  // Releasing a pointer variable:
  Dispose(P);

  // Creating a pointer array variable:
  ReallocMem(List, Count * SizeOf(TSomeRecord));

  // Clearing a pointer array variable:
  for I := 0 to Count - 1 do
  begin
    Pointer(List^[I].Field2) := nil;
    List^[I].Field1 := 0;
    List^[I].Field2 := '';
    List^[I].Field3 := False;
  end;

  // Releasing a pointer array variable:
  Finalize(List^[0], Count);

Choose and/or combine as you like.

Lacquer

so you're suggesting I set SomeRecord to EmptyRecord everytime I want to clear it? That's simple enough I guess, but is that really the proper way? The record in question has a lot more fields, lets say a few hundreds plus fields with custom types, it's not unfeasable to declare such an EmptyRecord, but looks impractical if you consider the size of the constant declaration. – Cohleen

A more flexible definition of the constant would be EmptySomeRecord: TSomeRecord = (); and let the compiler fill in the zeros. – Compunction

And I'd probably implement a record method named Zeroise or Clear performed the assignment of the empty record. – Compunction

@David If you have a Delphi version that supports record methods, yes! – Lacquer

-1 I really don't like your edited version one little bit. The version before the edit was excellent. 1. You duplicate code relentlessly with the 3 assignments to the 3 fields. Use the helper function you wrote, ClearSomeRecord. Even better make it a record method. 2. Why declare EmptySomeRecord and not use it in ClearSomeRecord? 3. SetLength initializes new elements to zero, please don't do it again. 4. Don't use GetMem, Realloc etc. to re-implement dynamic arrays. Use dynamic arrays. – Compunction

@David These are just a few different solutions from which OP can choose and/or combine. Furthermore, OP asked on how to deal with various pointer types of his record and record-array, hence the use of ReallocMem and Finalize. I will let the original answer stand out more. – Lacquer

Answer 4

With SomeRecord: TSomeRecord, SomeRecord will be an instance/variable of type TSomeRecord. With SomeRecord: ^TSomeRecord, SomeRecord will be a pointer to a instance or variable of type TSomeRecord. In the last case, SomeRecord will be a typed pointer. If your application transfer a lot of data between routines or interact with external API, typed pointer are recommended.

new() and dispose() are only used with typed pointers. With typed pointers the compiler doesn't have control/knowlegde of the memory your application is using with this kind of vars. It's up to you to free the memory used by typed pointers.

In the other hand, when you use a normal variables, depending on the use and declaration, the compiler will free memory used by them when it considers they are not necessary anymore. For example:

function SomeStaff();
var
    NativeVariable: TSomeRecord;
    TypedPointer: ^TSomeRecord;
begin
    NaviveVariable.Field1 := 'Hello World';

    // With typed pointers, we need to manually
    // create the variable before we can use it.
    new(TypedPointer);
    TypedPointer^.Field1 := 'Hello Word';

    // Do your stuff here ...

    // ... at end, we need to manually "free"
    // the typed pointer variable. Field1 within
    // TSomerecord is also released
    Dispose(TypedPointer);

    // You don't need to do the above for NativeVariable
    // as the compiler will free it after this function
    // ends. This apply also for native arrays of TSomeRecord.
end;

In the above example, the variable NativeVariable is only used within the SomeStaff function, so the compiler automatically free it when the function ends. This appy for almost most native variables, including arrays and records "fields". Objects are treated differently, but that's for another post.

Penetrance