Recent

Author Topic: [SOLVED] To Free or not to Free. That is the question  (Read 3679 times)

ASerge

  • Hero Member
  • *****
  • Posts: 2223
Re: To Free or not to Free. That is the question
« Reply #15 on: April 20, 2021, 01:30:00 am »
I think the programmer would be better off getting an access violation which would hopefully cause him/her to fix the error.
FreeAndNil brings it closer. Without zeroing, the error can be hidden for a long time.

440bx

  • Hero Member
  • *****
  • Posts: 3944
Re: To Free or not to Free. That is the question
« Reply #16 on: April 20, 2021, 01:49:39 am »
I think the programmer would be better off getting an access violation which would hopefully cause him/her to fix the error.
FreeAndNil brings it closer. Without zeroing, the error can be hidden for a long time.
I basically agree with what you stated above.  What I find sloppy is that when a class is Destroy()-ed, the pointer (apparently) isn't set to nil, nor when it is simply freed.  It has to be FreeAndNil. 

It seems to me that, there should be one way to "release" a class that takes care of everything that needs to be taken care of when it is released/freed, not three (3) different ways that all seem to have, at least, some holes in them.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: To Free or not to Free. That is the question
« Reply #17 on: April 20, 2021, 09:17:28 am »
I think the programmer would be better off getting an access violation which would hopefully cause him/her to fix the error.
FreeAndNil brings it closer. Without zeroing, the error can be hidden for a long time.

This only helps for the reference passed to FreeAndNil. If you copied the reference to other classes then those won't be set to Nil once FreeAndNil is called on the original.

Thaddy

  • Hero Member
  • *****
  • Posts: 14204
  • Probably until I exterminate Putin.
Re: [SOLVED] To Free or not to Free. That is the question
« Reply #18 on: April 20, 2021, 09:27:08 am »
That is my whole point expressed more eloquently.
Specialize a type, not a var.

jcmontherock

  • Full Member
  • ***
  • Posts: 234
Re: [SOLVED] To Free or not to Free. That is the question
« Reply #19 on: April 20, 2021, 11:03:08 am »
I have a more generally question: Do we have to Free or FreeAndNil every global Object we have created in the app before
closing it ?
Windows 11 UTF8-64 - Lazarus 3.2-64 - FPC 3.2.2

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: [SOLVED] To Free or not to Free. That is the question
« Reply #20 on: April 20, 2021, 04:39:44 pm »
I have a more generally question: Do we have to Free or FreeAndNil every global Object we have created in the app before
closing it ?

If it isn't freed through some other means (e.g. part of a TObjectList with OwnsObjects set to True, a TComponent-descendant with a Owner set or an object instance which is used only with interfaces) then yes, you need to free each and every object.

pcurtis

  • Hero Member
  • *****
  • Posts: 951
Re: [SOLVED] To Free or not to Free. That is the question
« Reply #21 on: April 20, 2021, 04:56:34 pm »
I think he means is it enough just to Free or is it better to FreeAndNil?
Windows 10 20H2
Laz 2.2.0
FPC 3.2.2

howardpc

  • Hero Member
  • *****
  • Posts: 4144
Re: [SOLVED] To Free or not to Free. That is the question
« Reply #22 on: April 20, 2021, 06:55:40 pm »
Free is sufficient.
The app is closing.
The OS will manage and reallocate the memory it allocated to the app from that point on. The app is dead and gone.

ASerge

  • Hero Member
  • *****
  • Posts: 2223
Re: [SOLVED] To Free or not to Free. That is the question
« Reply #23 on: April 20, 2021, 07:07:11 pm »
I think he means is it enough just to Free or is it better to FreeAndNil?
For local (not used twice) variable, or used only inside class/unit (rarely) - Free is sufficient.
For a global variable (typed constants), public fields (or are the basis for public properties) - FreeAndNil.
If you mix interfaces and classes - always use FreeAndNil.
Fortunately, in FPC, the FreeAndNil procedure is not inlined, which makes it a little more efficient (there is no code bloat, as in Delphi).

By the way, for some reason, ReallocMem(P, 0) is rarely used. Instead, it is often written FreeMem(P); P := nil. Although the first is more effective and safer (check for nil).

 

TinyPortal © 2005-2018