[solved] TBitmap free or destroy

[dcelso]

¿Hello, anyone knows the difference bettween free a tbitmat with .free o .destroy?

[Blaazen]

Press Alt+Up and you will see:

Code: [Select]

procedure TObject.Free;

        begin
           // the call via self avoids a warning
           if self<>nil then
             self.destroy;
        end;
             
So you see that Free calls Destroy.

And even better than "BMP.Free;" can be:

Code: [Select]

FreeThenNil(BMP);

[dcelso]

 , thanks. I'll remember from now.

[dcelso]

Then, if I need do it in a loop (of minimum 1000 times), and I control well the non null access,
is it better use .destroy to gain performance and do faster the application.?

[taazz]

you should not create and destroy bitmaps in a loop you can clear and reuse them as needed it ill be faster mainly from avoiding to re create all the internal structures and memory allocation and re allocation etc.

[User137]

And even better than "BMP.Free;" can be:

Code: [Select]

FreeThenNil(BMP);

I have seen this typo one or more times before. FreeAndNil(object) is correct form.

[Blaazen]

It's not typo, they exist both.
If you have enough time: http://www.mail-archive.com/lazarus@lists.lazarus.freepascal.org/msg19483.html
There are maybe 100 mails but honestly, I did not fully catch the difference 

[dcelso]

I not find FreeThenNil fuction unit in lazarus 1.1 (daily). Only I found FreeAndNil on sysutilh.inc

Is This function in another unit?

[User137]

It was in LCLProc unit, so it's not found in Delphi either.

[dcelso]

 , i saw it.

Code: [Select]

procedure FreeThenNil(var obj);
begin
  if Pointer(obj) <> nil then
  begin
    TObject(obj).Free;
    Pointer(obj) := nil;
  end;
end;

 procedure FreeAndNil(var obj);
      var
        temp: tobject;
      begin
        temp:=tobject(obj);
        pointer(obj):=nil;
        temp.free;
 end;
But I don't see the difference, both do the same for me.
Anyone can explain me the real difference in a application, for example, like me, a loop.
Thanks

[Ask]

FreeAndNil will crash if object destructor accesses Self.
FreeThenNil is not thread-safe, since there is a window for a race between destroying an object and clearing the reference.

[taazz]

It's not typo, they exist both.
If you have enough time: http://www.mail-archive.com/lazarus@lists.lazarus.freepascal.org/msg19483.html
There are maybe 100 mails but honestly, I did not fully catch the difference 

for a small example of the differences on usage take a look at  http://www.lazarus.freepascal.org/index.php/topic,19207.msg109134.html#msg109134 this should give you an idea about the problems that might raise. Let me also add at this point that using freeandnil makes extending components a bit easier avoiding some of the flow problems that might be introduced on a descendant component from, usually, a different developer, who might or might not have the time to properly analyze the underline code.

FreeAndNil will crash if object destructor accesses Self.

I'd like some example of this, as far as I can understand freeandnil should set the variable holding the reference to the object to nil not the self "variable" of the object. If it does play havoc with the self "variable" then there is something wrong that needs investigation.

[howardpc]

A destructor that accesses Self is poorly written, and normally ought to crash. So you are safer sticking to FreeAndNil (unless you really know what you are doing, or imagine you do).

[Ask]

freeandnil should set the variable holding the reference to the object to nil not the self "variable" of the object.

Yes, I wrote too hastily. I meant "if object destructor accesses Self indirectly".
For example, consider TForm.Destroy which calls "OnDestroy" event handler,
which might be written by another programmer and carelessly access "Form1.SomeProperty".
(Actual TForm.Destroy does not work so simply, it is just an example).

[taazz]

thank you for the clarification and I agree.

Yes, I wrote too hastily. I meant "if object destructor accesses Self indirectly".
For example, consider TForm.Destroy which calls "OnDestroy" event handler,
which might be written by another programmer and carelessly access "Form1.SomeProperty".

thank you for the clarification.

(Actual TForm.Destroy does not work so simply, it is just an example).

It does not matter how complicated the logic behind the destruction process is the variable has been set to nil before the destructor is called so it should raise an exception.