Forum > General

Out Parameter - Test program - funny behaviour

<< < (2/5) > >>

Basile B.:
My point is more that it shouldn't be allowed at all to use the same parameter as in and out. The fact is that IRL everyone would have written the function:


--- Code: ---function(var Line: string; out current char): boolean;
--- End code ---

It's bad luck you've been faced to this crazy corner case.
Though, interesting to analyze. The link i've put in my first answer EXACTLY describes the same thing.

jc99:

--- Quote from: BBasile on June 13, 2015, 09:08:11 am ---My point is more that it shouldn't be allowed at all to use the same parameter as in and out. The fact is that IRL everyone would have written the function:


--- Code: ---function(var Line: string; out current char): boolean;
--- End code ---

It's bad luck you've been faced to this crazy corner case.
Though, interesting to analyze. The link i've put in my first answer EXACTLY describes the same thing.

--- End quote ---
1. I try to make a different point: If it is allowed, it should work. Or if it isn't, there should be a warning.
2. Your answer DOES describe the same thing. What I tried to point out that dpc and fpc handle the code differently.
in Delphi the program fails on first call. In FPC the first call seems OK and the program fails on second call.

jc99:
I know it's not good to reply to your own diskusion, but there is new info:
Subject closed:

--- Quote from: Jonas_Maebe link=http://bugs.freepascal.org/view.php?id=28279 ---Other people have already answered in the forum. See also the discussion on the fpc mailing list: http://lists.freepascal.org/pipermail/fpc-devel/2015-June/thread.html ("ref count issue with out param"). Your remark regarding the warning (or rather, why a warning that always works is impossible to add) is addressed in http://lists.freepascal.org/pipermail/fpc-devel/2015-June/035706.html

--- End quote ---
I am not so happy that the issue is marked resolved.
Because (i hope) there is an ongoing discusion about this.
Nobody seems to care about the point I try to make:
You start with a

--- Code: ---function foo(aPar1:TSomething;var aPar2:TSomething):TSomethingElse;

--- End code ---
You test is, release it.--> Valid.

SomeOne (else) uses your function.

--- Code: ---while foo(s1,s1) do [...]

--- End code ---
He tests his code, still valid.

Years later the compiler has a new feature (Hints and out-params)
You came across your old function
and since you only write to aPar2 (and you want get rid of the annoying hint that the variable is not initialized.
you change the var to out.
by this you make someone else's code WRONG.
I think that some deserves a warning that his formerly valid code may have problems now.

I am fully aware that you can not warn everybody with everything. But a warning when a parameter is obviously handed twice (or more) to a routine with one of which is an "out" would be a start.


--- Quote from: jc99 on June 13, 2015, 12:00:16 am ---[...]
Found Workaround3: declare the function inline

--- End quote ---
And also a function should not change it's (obvious) behavior when declared inline (or not). If you are a good programmer then you normally put your "inline" in a compiler
-def like

--- Code: ---function foo([...]):TSomething; {$IFDEF SUPPORTS_INLINE}inline;{$ENDIF}

--- End code ---

The next point is:
You use this function:

--- Code: ---var p1,p2:string;
[...]
  p1:='ABCDE';
  while foo(p1,p2) do
     p1:=p2;
[...]

--- End code ---
That is obviously VALID code.
then someone ads a new fancy optimization to the compiler
Namely: when a variable is only used to fill a parameter it can be replaced with that variable, to get rid of an obvious unnecessary copy.
The formerly valid code starts to behave erratic. which is a very unpleasant thing, if you try to debug a large project.

At some point

--- Code: ---i := i + 1;

--- End code ---
is not valid anymore because you use variable i as an input and also as a target of that code.
(just kidding)

Thaddy:
Since I noticed from the discussions that only some DXE's were tested for reference:
D7 has the same  behavior  The out parameter is initialized to nil. Accordingly the output is nothing.
Only with the var parameter, D7 outputs the separate characters.
If you use the same variable as input for both parameters it gets reset to nil.
So from a delphi compatibility  point of view, you may hope for documentation of this behavior but it won't ever be "fixed" in any other way.

jc99:

--- Quote from: Thaddy on June 15, 2015, 05:52:33 pm ---Since I noticed from the discussions that only some DXE's were tested for reference:
D7 has the same  behavior  The out parameter is initialized to nil. Accordingly the output is nothing.
Only with the var parameter, D7 outputs the separate characters.

--- End quote ---
DXE2 was only the newest Compiler availible for me, If i wanted I could Do a synopsis from tp3 over bp7  via d2, d4 to dxe2 where i stoped buying New compilers. My Code also developed through the different versions. BTW Bp7 was my favorite for a long time.
But as You See above there was a link to a Delphi Blog that they try to fix that in newer versions.
So i only tried the newer versions.
The reason i prefered Pascal over C, C++, C#, Java (and all the other New shit) was the structure and encapulation. And Not have to think about, oh when i Do this then the reference count is Not Set correctly ... To me that is against the Basic philosophy of Pascal.


Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version