🚀 go-pugleaf

On Sat, 09 May 1998 17:31:24 GMT, ullrich@math.okstate.edu wrote:

>In article <pacsoftEsnnEB.2nE@netcom.com>,
>  pacsoft@netcom.com (Wilhelm Sarasalo) wrote:
>>
>> A long time ago I looked at the source for tList.Destroy and it didn't
>> seem right because it overrode tObject.Destroy, but didn't call it, it
>> just called clear that sets count and capacity to 0.
>>
>> Now I bought a debugging tool called BoundsChecker from NuMega. It
>> reported resource leakage where I had tList.create/tList.free pairs.
>>
>> I modified classes.pas adding inherited destroy to tList.destroy,
>> BoundsChecker quit reporting any leakage. Programs didn't change their
>> behavior.
>
>    TList descends directly from TObject. TObject's Destroy method
>doesn't do anything, so the program behaves the same whether
>inherited Destroy is called or not. (The 32 bytes(?) allocated
>for _any_ object gets freed by _any_ destructor, and there's
>nothing else for TObject.Destroy to do.)
>
>      Evidently BoundsChecker doesn't understand this.

It is also possible that Wilhelm simply forgot that TList doesn't
destroy any objects to which it may point.

For example, 

var MyList: TList; TestObj: TObject;
begin
  MyList := TList.Create;
  TestObj := TObject.Create;
  MyList.Add(TestObj);
  MyList.Free
end;

will cause a leak, since TestObj is never freed.

Could this be the cause of his problem?