That code's safe from a memory POV, but I wouldn't have coded it like
that personally, because to me, the intentions aren't clear. I believe
that the fact that you had to go and look at the implementation supports
my suggestion of trying to clarify intentions.
I haven't used TFindFile (so unsure of all the code), but personally I
would have coded TFindFile so that you would use it along the lines of:
tf := TFindFile.Create;
try
if tf.SearchForFiles then // SearchForFiles
does a search and returns a boolean
Memo1.Lines.Assign(tf.FoundFiles); // where FoundFiles is a
TStringList _property_ of TFindFile
finally
tf.Free;
end;
Neven's free to disagree. I'm not telling people what to do, I'm just
telling you what I find easiest to follow.
C.
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of 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."
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Xander (GMail)
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.
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Leigh Wanstead
I think you need this one
http://v.mahon.free.fr/pro/freeware/memcheck
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Jeremy Coulter
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 :-)
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi@delphi.org.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to [EMAIL PROTECTED] with Subject: unsubscribe
