[DUG] Dumb Friday Question

[John Bird]

I have seen an exact similar case in one of the few external components I
use - TFindFile
 
which has code like:
 
s:TStringlist is a private variable in the FindFiles unit,
 
function TFindFile.SearchForFiles: TStringList;
begin
  s.Clear;
  try
    FileSearch(Path);
  finally
    Result := s;
  end;
end;

the only reference to s in the FileSearch function is
 
     s.Add(inPath + Rec.Name);

The component also has:
 
constructor TFindFile.Create(AOwner: TComponent);
begin
  inherited Create(AOwner);
  Path := IncludeTrailingBackslash(GetCurrentDir); 
  FileMask := '*.*';
  FileAttr := [ffaAnyFile];
  s := TStringList.Create;
end;
 
destructor TFindFile.Destroy;
begin
  s.Free;
  inherited Destroy;
end;

 
I call it from my program with code like:
 
  strlist:TStringList;
 
and

  strlist:=FindFile1.SearchforFiles;
 
That is I do no creating or freeing of the strlist myself - the component
does all of the housework is my understanding.  Thats one of the reasons I
use it, as it encapsulates a few fiddly things like this.
 
Is this correct use or is this creating memory leaks?  I found errors if I
tried to create or free the strlist myself - and was advised that
effectively the component was doing this and I didn't need to.
 
[This is a utility I have for recursive folder searches of source files for
a matching string displaying matches in a stringgrid - a sort of visual Grep
- would be happy to share it if anyone can point out any errors or
improvements] 
 
>From the Help
 
"TStringList.Clear:
 
Deletes all the strings from the list.
 
procedure Clear; override;
 
Description
 
Call clear to empty the list of strings. All references to associated
objects are also removed. However, the objects themselves are not freed."
 
 

John 

 -----Original Message-----
From: delphi-bounces at delphi.org.nz [mailto:delphi-bounces at delphi.org.nz] On
Behalf Of Xander (GMail)
Sent: Friday, 4 May 2007 2:02 p.m.
To: 'NZ Borland Developers Group - Delphi List'
Subject: RE: [DUG] Dumb Friday Question



Jeremy,

 

If the function returns a TStringList then it should be the responsibility
of the caller of that function to FREE the returned TStringList after it has
finished using it. You cannot free it inside the function.

 

Regards

 


  _____  


From: delphi-bounces at delphi.org.nz [mailto:delphi-bounces at delphi.org.nz] On
Behalf Of Leigh Wanstead
Sent: Friday, May 04, 2007 1:55 PM
To: vss at vss.co.nz; NZ Borland Developers Group - Delphi List
Subject: RE: [DUG] Dumb Friday Question

 

Hi Jeremy,

 

I think you need this one http://v.mahon.free.fr/pro/freeware/memcheck

 

;-)

 

Regards

Leigh

www.smootharm.com

-----Original Message-----
From: delphi-bounces at delphi.org.nz [mailto:delphi-bounces at delphi.org.nz]On
Behalf Of Jeremy Coulter
Sent: Friday, 4 May 2007 1:28 p.m.
To: delphi at delphi.org.nz
Subject: [DUG] Dumb Friday Question

Hi All. This is a question that might be infulenced by some serious lack of
sleep :-)

 

I have a funtion. Its return result is a TStringlist.

In my code I create a TStringlist then add my values to it, then pass this
to the RESULT varaible for the function.

 

Now,  this is prob. an obvious answer than I prob. do actually know, but if
I got:-

 

sResult := TStringList.create;

sResult.add('blah');

Result:=sResult;

 

Then if I free sResult, then I loss the values I added, and the result is
empty as you would expect.

But the issue I have is, so if I DONT free sResults, what happens to it?
Surley it stays in memory,a dn I would end up with a memory leack after
repeaditive calls. Is that right? Or is because the variable is function
specific its free by default etc?

Its a basic question I know....but the more I thought about it the more
uncertain I became....I really need some sleep so that prob. the real
probelm :-)

 

Jeremy

 

 



__________ NOD32 2238 (20070503) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.adventureeducation.co.nz/pipermail/delphi/attachments/20070504/5c58dffd/attachment-0001.html