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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > 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 :-) _______________________________________________ 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
