🚀 go-pugleaf

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.

David C. Ullrich



-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading

In article <35551513.72185262@news.mia.bellsouth.net>,
  MauriceV@bellsouth.net wrote:
>
> 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?

      He says that the problem went away when he modified classes.pas,
adding "inherited Destroy" to TList.Destroy. If he's making the
(very common) error you suggest that would be a _real_ leak, and
this would not have fixed it.

David C. Ullrich

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading

On Sun, 10 May 1998 18:43:41 GMT, ullrich@math.okstate.edu wrote:

>      He says that the problem went away when he modified classes.pas,
>adding "inherited Destroy" to TList.Destroy. If he's making the
>(very common) error you suggest that would be a _real_ leak, and
>this would not have fixed it.

Oops. That should teach me to read the original posts carefully.

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?