[fpc-pascal] methods of an object to create others objects
We can to use methods of an object to create others objects, or this is a bad programming practice? eg: var obj1, obj2: TmyObject; begin obj1 := tobj1.create; //ok obj2 := obj1.createObj; // is this recommended? try //... finally obj1.free; obj2.free; end; end; Why I ask this: If not exists the variable obj2 in call obj1.createObj will happen a memory leak, right? Because there is not variable to release. Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On Mon, 5 Jul 2010 15:48:40 -0300
Marcos Douglas wrote:
Questions of style: just a personal opinion.
> We can to use methods of an object to create others objects, or this
> is a bad programming practice?
> eg:
> var
> obj1, obj2: TmyObject;
> begin
> obj1 := tobj1.create; //ok
> obj2 := obj1.createObj; // is this recommended?
> try
> //...
> finally
> obj1.free;
> obj2.free;
> end;
> end;
How else can one program using object orientation?
VAR
t1, t2 : Text ;
BEGIN
t1 := Text('abcdefghi') ;
t2 := t1.section(3,7) ;
t2.write ; // 'cdefg', if I'm right ;-)
END
Or do you mean to copy a (referenced) object?
> Why I ask this:
> If not exists the variable obj2 in call obj1.createObj will happen a
> memory leak, right? Because there is not variable to release.
Do you mean using a function as a statement? (for its so-called "side effect")
*This*, in my opinion, is very bad programming practice. But it's just an
opinion.
First, a function that has effects is already bad, except for recording data on
the object (eg metadata, or memoization). Second, if you really want it to *do*
something in addition to *making* its return value, you should make this
"anomaly" obvious by writing the effect in an external proc (called by the
func). So that, when you need the effect but not the value, just call the proc.
> Marcos Douglas
Denis
vit esse estrany ☣
spir.wikidot.com
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On 05/07/2010 19:48, Marcos Douglas wrote: We can to use methods of an object to create others objects, or this is a bad programming practice? eg: var obj1, obj2: TmyObject; begin obj1 := tobj1.create; //ok obj2 := obj1.createObj; // is this recommended? This is used very often like this, so yes this is fine. try //... finally obj1.free; obj2.free; end; end; Why I ask this: If not exists the variable obj2 in call obj1.createObj will happen a memory leak, right? Because there is not variable to release. Not exactly sure what you mean? There are 2 problems that can happen: 1) "obj1.createObj" returns no object and obj2 will be nil, then of course calling obj2.foo would crash. If "obj1.createObj" can return nil, then you must check for this. 2) "obj1.createObj" crashes, then you are still before the try, and obj1 will not be freed => so yes leak You can either do 2 nested try finally, or the following: var obj1, obj2: TmyObject; begin // make sure they are both initialized // obj1.free works correct, if obj1 is nil obj1 := nil; obj2 := nil; try obj1 := tobj1.create; obj2 := obj1.createObj; //... finally obj1.free; obj2.free; end; end; ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On Mon, Jul 5, 2010 at 4:07 PM, spir wrote:
> On Mon, 5 Jul 2010 15:48:40 -0300
> Marcos Douglas wrote:
>
> Questions of style: just a personal opinion.
>
>> We can to use methods of an object to create others objects, or this
>> is a bad programming practice?
>> eg:
>> var
>> obj1, obj2: TmyObject;
>> begin
>> obj1 := tobj1.create; //ok
>> obj2 := obj1.createObj; // is this recommended?
>> try
>> //...
>> finally
>> obj1.free;
>> obj2.free;
>> end;
>> end;
>
> How else can one program using object orientation?
>
> VAR
> t1, t2 : Text ;
> BEGIN
> t1 := Text('abcdefghi') ;
> t2 := t1.section(3,7) ;
> t2.write ; // 'cdefg', if I'm right ;-)
> END
>
> Or do you mean to copy a (referenced) object?
>
>> Why I ask this:
>> If not exists the variable obj2 in call obj1.createObj will happen a
>> memory leak, right? Because there is not variable to release.
>
> Do you mean using a function as a statement? (for its so-called "side effect")
> *This*, in my opinion, is very bad programming practice. But it's just an
> opinion.
> First, a function that has effects is already bad, except for recording data
> on the object (eg metadata, or memoization).
What do you mean "a function has effects is already bad"?
A function/procedure always has effects, don't?
> Second, if you really want it to *do*
> something in addition to *making* its return value, you should make this
> "anomaly"
> obvious by writing the effect in an external proc (called by the func). So
> that, when you
> need the effect but not the value, just call the proc.
Well... I think something is smell bad with this code :)
But I will try a better example:
Imagine a text file. Each line correspond an object. A parser creates
these objects. So, in a loop:
for I := 0 to Lines.Count-1 do
begin
line := Lines[I];
//(...)
obj := Parser.GetObj(line);
try
//(...)
finally
obj.Free;
end;
end;
The object Parser creates obj through the line string.
If the *line* is broke, Parser do not can create an object and an
Exception is created; the *obj* never is nil because there are
exception handling.
Do you have a better idea for this example?
Marcos Douglas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] question about changing default ASCII table in the fpc 2.2.0 IDE
On 25 Jun 10, at 8:07, Noel and Marie wrote: Hi Noel, > Thanks Tomas. I didn't see your promise to look at the problem. Sorry, it took somewhat longer, but the results are here: 1) It works as expected if _not_ using unit Crt. 2) There is a bug in implementation of unit Crt for Windows. This bug stems from May 2006 already and it was a result of a patch from Maxim Ganetsky trying to fix bug #6785 (http://bugs.freepascal.org/view.php?id=6785). Since that patch, all output with unit Crt uses the so called ANSI code page under Windows which is IMHO wrong. I've added a comment to bug #6785 and filed a new bug report (http://bugs.freepascal.org/view.php?id=16846) - you may want to monitor that one in order to be notified when it gets fixed. Until the bug is fixed, there are several possible solutions for you, e.g.: - You may comment line 699 (and preferably also line 743) in your local copy of rtl/win/crt.pp (trunk version from SVN) and recompile RTL (and packages). That isn't a complete fix, but it should probably be sufficient for your needs. - If you only need to output this one particular character, you may do so using the particular Win32 API directly. Admittedly not very nice and certainly not portable, but at least a possible workaround. - If you don't need unit Crt, you may simply remove it from your uses clause. > I have just relied on email replies for comments etc. How do I look at all > comments, other questions, etc on the Web? Sorry, I'm not sure if I understand this question. Do you refer to an archive of this mailing list? If so, you can find a link on the FPC WWW pages (under Mailing lists). Hope this helps Tomas > - Original Message - > From: "Tomas Hajny" > To: "FPC-Pascal users discussions" > Sent: Thursday, June 24, 2010 11:59 PM > Subject: Re: [fpc-pascal] question about changing default ASCII table in the > fpc 2.2.0 IDE > > > On Thu, June 24, 2010 06:41, Noel and Marie wrote: > > Hello, > > > > I would like to print a square root symbol using write(chr(251)); as I > > could before SP3 for XP was installed on my PC. > > > > Currently am getting a superscript 1 rather than the square root symbol > > from > > write(chr(251)). > > > > I've tried the following kind suggestions of Tomas Hajny, unfortunately > > without success: > > > > 1. In a command shell I entered > > CHCP 437 and then ran the program > > > > 2. Modified the source code to include the Windows unit and added line > > setConsoleOutputCP(437);, > > compiled and then ran the program. > > > > > > I examined the registry settings in directory Codepage. > > Name Data > > (default ) (value not set) > > ... > > ACP1252 > > MACCP1 > > OEMCP850 > > OEMHALvgaoem.fon > > > > Changed OEMCP to 437 and got an accented 'u'. Then restored > > the system. > > > > I wonder if anyone can suggest a solution to the problem. > > I still intend to have a look at it (as promised previously), just had no > time for that (if noone else provides answer till then). > > Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
Hi Martin On Mon, Jul 5, 2010 at 4:33 PM, Martin wrote: > On 05/07/2010 19:48, Marcos Douglas wrote: >> >> We can to use methods of an object to create others objects, or this >> is a bad programming practice? >> eg: >> var >> obj1, obj2: TmyObject; >> begin >> obj1 := tobj1.create; //ok >> obj2 := obj1.createObj; // is this recommended? >> > > This is used very often like this, so yes this is fine. > >> try >> //... >> finally >> obj1.free; >> obj2.free; >> end; >> end; >> >> Why I ask this: >> If not exists the variable obj2 in call obj1.createObj will happen a >> memory leak, right? Because there is not variable to release. >> > > Not exactly sure what you mean? > > There are 2 problems that can happen: > > 1) > "obj1.createObj" returns no object and obj2 will be nil, then of course > calling obj2.foo would crash. > If "obj1.createObj" can return nil, then you must check for this. > > 2) > "obj1.createObj" crashes, then you are still before the try, and obj1 will > not be freed => so yes leak None of these problems will happen, because I treat all them. > You can either do 2 nested try finally, or the following: > > var > obj1, obj2: TmyObject; > begin > // make sure they are both initialized > // obj1.free works correct, if obj1 is nil > obj1 := nil; > obj2 := nil; > try > obj1 := tobj1.create; > obj2 := obj1.createObj; > //... > finally > obj1.free; > obj2.free; > end; > end; I use this technique a lot, but thanks :) Unfortunately, this is not the *problem*. The ask is: If a function creates, inside, a object and there is no variable to receive this pointer, will happen a memory leak? In my eg before, this is Okay: obj2 := obj.createObj; The obj2 is a pointer to release. But, like that: obj1.createObj; //no variable to receive ...now, where is the pointer to release? Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On 05/07/2010 21:03, Marcos Douglas wrote: I use this technique a lot, but thanks :) Unfortunately, this is not the *problem*. The ask is: If a function creates, inside, a object and there is no variable to receive this pointer, will happen a memory leak? In my eg before, this is Okay: obj2 := obj.createObj; The obj2 is a pointer to release. But, like that: obj1.createObj; //no variable to receive ...now, where is the pointer to release? That would be, if a crash happens inside obj1.createObj? Because otherwise the obj is stored in obj2. If it happens in there, then handle it in there => there is result as variable. function TMyObject.creatObj : TSomeObj; begin result := TsomeObject.create; end; function TMyObject.creatObj : TSomeObj; begin result := TsomeObject.create; try DoFooBar; except result.Free; // will not be used by caller, but be aware it has still a value, which now is invalid end; end; In the line result := TsomeObject.create; the only crash that can happen is inside "create" => a crash in the constructor is handled by the compiler, the object will be freed. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On Mon, Jul 5, 2010 at 5:14 PM, Martin wrote: > > That would be, if a crash happens inside obj1.createObj? Because otherwise > the obj is stored in obj2. > > If it happens in there, then handle it in there => there is result as > variable. > > function TMyObject.creatObj : TSomeObj; > begin > result := TsomeObject.create; > end; > > > function TMyObject.creatObj : TSomeObj; > begin > result := TsomeObject.create; > try > DoFooBar; > except > result.Free; // will not be used by caller, but be aware it has still a > value, which now is invalid > end; > end; > > In the line > result := TsomeObject.create; > > the only crash that can happen is inside "create" => a crash in the > constructor is handled by the compiler, the object will be freed. Thanks, but lets continue :) In another words, get you method: > function TMyObject.creatObj : TSomeObj; > begin > result := TsomeObject.create; > end; If I have a variable myObj, I can do this: someObj := myObj.createObj; This is the same: someObj := TsomeObject.create; Rigth? But if a remove the variable *someObj* and call like this: myObj.createObj; // I _removed_ the *someObj* here!!! What will happen with the "result" variable? Is it released by the compiler? Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On Mon, 5 Jul 2010 17:26:52 -0300 Marcos Douglas wrote: >[...] > But if a remove the variable *someObj* and call like this: > myObj.createObj; // I _removed_ the *someObj* here!!! > > What will happen with the "result" variable? Is it released by the compiler? No. This will create a mem leak. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On 05/07/2010 21:26, Marcos Douglas wrote: If I have a variable myObj, I can do this: someObj := myObj.createObj; This is the same: someObj := TsomeObject.create; Rigth? But if a remove the variable *someObj* and call like this: myObj.createObj; // I _removed_ the *someObj* here!!! What will happen with the "result" variable? Is it released by the compiler? that is the same as if you wrote TsomeObject.create; without assigning the created object to a variable. Both cause a memory leek. Mind you just because "Create" is a constructor does not protect it from being called without using the result. Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On Mon, Jul 5, 2010 at 5:30 PM, Mattias Gaertner wrote: > > No. This will create a mem leak. Thanks Mattias, I expect that... On Mon, Jul 5, 2010 at 5:39 PM, Martin wrote: > > that is the same as if you wrote > > TsomeObject.create; > > without assigning the created object to a variable. Both cause a memory > leek. > > Mind you just because "Create" is a constructor does not protect it from > being called without using the result. Yes, as Mattias said too. This type of construction should be banned, no? Different this, some times I use OUT parameters to force the caller to receive the result. Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On Mon, 5 Jul 2010 17:46:39 -0300 Marcos Douglas wrote: > On Mon, Jul 5, 2010 at 5:30 PM, Mattias Gaertner > wrote: > > > > No. This will create a mem leak. > > Thanks Mattias, I expect that... > > > On Mon, Jul 5, 2010 at 5:39 PM, Martin wrote: > > > > that is the same as if you wrote > > > > TsomeObject.create; > > > > without assigning the created object to a variable. Both cause a memory > > leek. > > > > Mind you just because "Create" is a constructor does not protect it from > > being called without using the result. > > Yes, as Mattias said too. > > This type of construction should be banned, no? No. TForm1.Create(Application); Application will free the TForm1. > Different this, some times I use OUT parameters to force the caller to > receive the result. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On 5 July 2010 22:03, Marcos Douglas wrote: > The ask is: > If a function creates, inside, a object and there is no variable to > receive this pointer, will happen a memory leak? Yes you will have a memory leak. Easy way to test is to enable the heaptrc unit (compiler option -gh). On terminating the application, the heaptrc unit will dump memory usage output to the console window. If the object returned is a reference counted object, then I think it will be freed (though not working with the interface instance itself is bad practice). Remember FPC doesn't have garbage collection like Java or .NET. Rule of thumb is that if you created it, you need to free it. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On Mon, 5 Jul 2010, Graeme Geldenhuys wrote: On 5 July 2010 22:03, Marcos Douglas wrote: The ask is: If a function creates, inside, a object and there is no variable to receive this pointer, will happen a memory leak? Yes you will have a memory leak. Easy way to test is to enable the heaptrc unit (compiler option -gh). On terminating the application, the heaptrc unit will dump memory usage output to the console window. If the object returned is a reference counted object, then I think it will be freed (though not working with the interface instance itself is bad practice). Remember FPC doesn't have garbage collection like Java or .NET. Rule of thumb is that if you created it, you need to free it. I would even add to this that you need to guard for exceptions: A:=TSomeClass.Create; try // do stuff finally A.Free; Make sure it is freed, even in case of exception. end; If your classes have more global scope, rule of thumb is to create objects in the form/datamodule's OnCreate event, and to free them in the OnDestroy event. (I always code the create and free statements together, so as not to forget this). Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
If Memory allocation is the point of discussion and you need to create objects ... You should nest the creations in order of usage. In your declarations you needed bot Object1 and Object2 as TMyObject; That said the proper usage would be: obj1:=TMyObject.Create; Try obj2:=TMyObject.Create; Try Obj1.DoSomething1; Obj2.DoSomething2; Finally FreeAndNil(Obj2); end; Finally FreeAndNil(Obj1); end; I would like to know what the purpose is for having an auxiliary constructor if they both reference createObj. Anything other than nested Exception Handling is very poor practice. On Mon, Jul 5, 2010 at 1:48 PM, Marcos Douglas wrote: > We can to use methods of an object to create others objects, or this > is a bad programming practice? > eg: > var > obj1, obj2: TmyObject; > begin > obj1 := tobj1.create; //ok > obj2 := obj1.createObj; // is this recommended? > try > //... > finally > obj1.free; > obj2.free; > end; > end; > > Why I ask this: > If not exists the variable obj2 in call obj1.createObj will happen a > memory leak, right? Because there is not variable to release. > > > Marcos Douglas > ___ > fpc-pascal maillist - fpc-pas...@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On Mon, 5 Jul 2010 16:51:54 -0300 Marcos Douglas wrote: > What do you mean "a function has effects is already bad"? > A function/procedure always has effects, don't? IMHO he means that a function should only return a value and not change the state of an object, a variable or any other program state at all. This is good practice but there are obvious cases where this rule makes no sense, for example boolean functions, that use the return value to indicate success/failure, etc. R. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] question about changing default ASCII table in thefpc 2.2.0 IDE
Thank you Tomas for tracking down the bug and filing the bug report. It was much appreciated. Cheers, Noel - Original Message - From: "Tomas Hajny" To: "FPC-Pascal users discussions" Cc: ; "Noel and Marie" Sent: Tuesday, July 06, 2010 5:32 AM Subject: Re: [fpc-pascal] question about changing default ASCII table in thefpc 2.2.0 IDE On 25 Jun 10, at 8:07, Noel and Marie wrote: Hi Noel, Thanks Tomas. I didn't see your promise to look at the problem. Sorry, it took somewhat longer, but the results are here: 1) It works as expected if _not_ using unit Crt. 2) There is a bug in implementation of unit Crt for Windows. This bug stems from May 2006 already and it was a result of a patch from Maxim Ganetsky trying to fix bug #6785 (http://bugs.freepascal.org/view.php?id=6785). Since that patch, all output with unit Crt uses the so called ANSI code page under Windows which is IMHO wrong. I've added a comment to bug #6785 and filed a new bug report (http://bugs.freepascal.org/view.php?id=16846) - you may want to monitor that one in order to be notified when it gets fixed. Until the bug is fixed, there are several possible solutions for you, e.g.: - You may comment line 699 (and preferably also line 743) in your local copy of rtl/win/crt.pp (trunk version from SVN) and recompile RTL (and packages). That isn't a complete fix, but it should probably be sufficient for your needs. - If you only need to output this one particular character, you may do so using the particular Win32 API directly. Admittedly not very nice and certainly not portable, but at least a possible workaround. - If you don't need unit Crt, you may simply remove it from your uses clause. I have just relied on email replies for comments etc. How do I look at all comments, other questions, etc on the Web? Sorry, I'm not sure if I understand this question. Do you refer to an archive of this mailing list? If so, you can find a link on the FPC WWW pages (under Mailing lists). Hope this helps Tomas - Original Message - From: "Tomas Hajny" To: "FPC-Pascal users discussions" Sent: Thursday, June 24, 2010 11:59 PM Subject: Re: [fpc-pascal] question about changing default ASCII table in the fpc 2.2.0 IDE On Thu, June 24, 2010 06:41, Noel and Marie wrote: > Hello, > > I would like to print a square root symbol using write(chr(251)); as I > could before SP3 for XP was installed on my PC. > > Currently am getting a superscript 1 rather than the square root symbol > from > write(chr(251)). > > I've tried the following kind suggestions of Tomas Hajny, unfortunately > without success: > > 1. In a command shell I entered > CHCP 437 and then ran the program > > 2. Modified the source code to include the Windows unit and added line > setConsoleOutputCP(437);, > compiled and then ran the program. > > > I examined the registry settings in directory Codepage. > Name Data > (default ) (value not set) > ... > ACP1252 > MACCP1 > OEMCP850 > OEMHALvgaoem.fon > > Changed OEMCP to 437 and got an accented 'u'. Then > restored > the system. > > I wonder if anyone can suggest a solution to the problem. I still intend to have a look at it (as promised previously), just had no time for that (if noone else provides answer till then). Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] methods of an object to create others objects
On Mon, 5 Jul 2010 16:51:54 -0300 Marcos Douglas wrote: > >> Why I ask this: > >> If not exists the variable obj2 in call obj1.createObj will happen a > >> memory leak, right? Because there is not variable to release. > > > > Do you mean using a function as a statement? (for its so-called "side > > effect") > > *This*, in my opinion, is very bad programming practice. But it's just an > > opinion. > > First, a function that has effects is already bad, except for recording data > > on the object (eg metadata, or memoization). > > What do you mean "a function has effects is already bad"? > A function/procedure always has effects, don't? A question of terminology. "Effect" usually means the changes a "routine" (function or procedure) lets once it has completed its task. Indeed, any routine can do changes, but we can make a difference between changes in routine's own local scope (usually on the stack) that disappear, and changes on the outer worlds that remain. The latter are called effect and are the purpose of procedures. (Hope I'm clear ;-) A function's purpose is to construct and return a given value. For instance the purpose of parser.getLine(source, pos) is seemingly clear; if it does an effect in addition to returning lines, then this effect is called "side-effect" because this is often considered bad practice. There are good reasons for this, mine are: * This is misleading: nothing in the apparent purpose of the func, and in its name, lets guess that there are permanent changes in the world's state. * It makes it hard to reason about the program. * It kills formal properties of functions that could be used to prove. For instance, the same func called twice with the same arguments may not return the same result. > > Second, if you really want it to *do* > > something in addition to *making* its return value, you should make this > > "anomaly" > > obvious by writing the effect in an external proc (called by the func). So > > that, when you > > need the effect but not the value, just call the proc. > > Well... I think something is smell bad with this code :) > But I will try a better example: > Imagine a text file. Each line correspond an object. A parser creates > these objects. So, in a loop: > > for I := 0 to Lines.Count-1 do > begin > line := Lines[I]; > //(...) > obj := Parser.GetObj(line); > try > //(...) > finally > obj.Free; > end; > end; > > The object Parser creates obj through the line string. > If the *line* is broke, Parser do not can create an object and an > Exception is created; the *obj* never is nil because there are > exception handling. I do not see the problem, since obj is explicitely free'ed... > Marcos Douglas Denis vit esse estrany ☣ spir.wikidot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
