🚀 go-pugleaf

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