[DUG] Dumb Friday Question

[Conor Boyd]

I do consider a constructor a function to some extent, but it's a
function which has compiler support.

I.e. the compiler guarantees to tidy up a partially constructed result
object if an exception gets raised in the constructor.

Also, everybody knows that a constructor returns a complex object; the
responsibility for freeing it is clear.

If I see a Delphi method returning an object, then I need to go and look
at the code to confirm the expected object lifetime.  By making
intentions clearer, the need to do that is reduced.

To me, as I said below, the intentions are clearer in the way that Rob,
Rohit & I suggested.

Cheers,

C.

-----Original Message-----
From: delphi-bounces at delphi.org.nz [mailto:delphi-bounces at delphi.org.nz]
On Behalf Of Neven MacEwan

You guys don't consider a constructor a function then?

I think its totally stylistic, if you want to have functions returning
objects fine, just make it plain that they do,

IMHO

> I would endorse Rob's answer here.
>
> I don't consider it just a question of potential leaks, it's about 
> making the intentions of your code clear.
>
> The intention of who has the responsibility for object lifetime is 
> much, much clearer in Delphi if your caller creates the Stringlist 
> that it wants populated and frees it afterwards.
>
> I'd tend to make the method a boolean function for example, so you can

> test the result of your stringlist filling method; e.g.
>
> Function PopulateString(const sl: TStringList): Boolean; Begin
>   //Over-simplified example
>
>   if sl.Add('My String') then
>     Result := True;
> End
>
> HTH,
>
> Conor
>
> -----Original Message-----
> From: delphi-bounces at delphi.org.nz 
> [mailto:delphi-bounces at delphi.org.nz]
> On Behalf Of Robert martin
>
> Your code would leak.  You are creating an object and not freeing it.

> The calling function that retrieves the result must handle the freeing

> of the object.
>
> It might be clearer if you just change the function to a procedure 
> that takes a TStringList as a parameter.  i.e
>
> //Replacement procedure
> procedrue NewProc (sl :TStringList);
> begin
>     sl.Add('Blah Blah');
> end;
>
> //Calling procedure
> procedure call
> var
>     AStringList : TStringList;
> begin
>     AStringList := TStringList.Create;
>     try
>        NewProc(AStringLIst);
>
>        ......
>
>     finally
>        AStringList.Free;
>     end;
>
> end;
>
> Hope that helps :)
>
> Jeremy Coulter wrote:
>   
>> 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 :-)