Presednce of operations...

[Mark- 29]

Hello,

 

This might seem silly. Used a few programming languages over the years. Would you expect the code below to produce the same result? 7

Did not find a reference in the help system.

procedure TestOrder;
var
 index,finalValue:integer;

 function ResultIsFive(var i:integer):integer;
 begin
  result:= 3 + 2;
  Inc(i);
 end;

begin
  index:=1;
  finalValue:=index + ResultIsFive(index);
  ShowMessage(IntToStr(finalValue));

  index:=1;
  finalValue:=ResultIsFive(index) + index;
  ShowMessage(IntToStr(finalValue));
end;

Thanks,

 

Mark

[corneliusdavid 214]

9 minutes ago, Mark- said:

Would you expect the code below to produce the same result? 7

Yes. Order is not important here because the function must be run before the expression can be evaluated.

[qubits 20]

Hi Mark,

 

no, compiler in my head says, 6 and 7. index passed as var, i is index, index is i and you inc it, change the order of your addition.

 

dave

[David Heffernan 2345]

1 hour ago, corneliusdavid said:

Yes. Order is not important here because the function must be run before the expression can be evaluated.

No I don't think that is true. 

[David Heffernan 2345]

This code exhibits undefined behaviour. In an expression like a + b, a and b can be evaluated in either order. The language does not mandate that order. 

 

If you want to make your code well defined the. You need to evaluate the function on one statement, and then perform the addition in another. 

 

finalValue := ResultIsFive(index);

Inc(finalValue, index);

 

Edited January 17, 2022 by David Heffernan

[corneliusdavid 214]

25 minutes ago, David Heffernan said:

In an expression like a + b, a and b can be evaluated in either order.

Yes, for simple variables but I'm pretty sure that functions have to be evaluated first. I ran a simple test of OP's code and verified before I answered. I ran it in Delphi 10.4; perhaps an earlier version of Delphi (or a compiler directive?) would change that.

 

29 minutes ago, David Heffernan said:

If you want to make your code well defined then you need to evaluate the function on one statement, and then perform the addition in another.

I totally agree with this. 

[Lajos Juhász 293]

I've also tested:

 

finalValue:=2*index + ResultIsFive(index);

 

the result 9. I guess this is one of the reasons why you should not write procedures with side effects. It can make a mission impossible to find the them.

[David Heffernan 2345]

8 hours ago, corneliusdavid said:

I'm pretty sure that functions have to be evaluated first. I ran a simple test of OP's code and verified before I answered.

That just tells you about this one piece of code and whichever compilers you happened to use. It doesn't prove a rule. 

 

If you look in a field and see that all the cows in that field are back and white, does that prove that all cows are black and white? 

[FPiette 383]

9 hours ago, corneliusdavid said:

I'm pretty sure that functions have to be evaluated first.

I'm pretty sure you are wrong and that it is not specified in languages.

 

[Stefan Glienke 2002]

2 hours ago, FPiette said:

I'm pretty sure you are wrong and that it is not specified in languages.

Usually it is left to right like in C# which is one of the few languages that has very little UB - https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/expressions#12623-run-time-evaluation-of-argument-lists

Edited January 18, 2022 by Stefan Glienke

[PeterBelow 238]

13 hours ago, David Heffernan said:

No I don't think that is true. 

In this case it is, but one should never make assumptions about in which order the parts of a complex expressions are evaluated. It may even change depending on compiler flags, e.g. optimization on or off, stack frames on or of, range and overflow checks.

[David Heffernan 2345]

1 hour ago, PeterBelow said:

In this case it is

I never said anything about this specific case. I am referring to universal rules that can be applied, or in this case not because they don't exist. See the black and white cow argument. 

[flcop 0]

9 hours ago, Lajos Juhász said:

finalValue:=2*index + ResultIsFive(index);

 

the result 9

My test in FPC, the result is 7,  so don't rely on the order.

[David Heffernan 2345]

1 hour ago, flcop said:

My test in FPC, the result is 7,  so don't rely on the order.

If FPC had given 9 that wouldn't have changed the conclusion 

[Anders Melander 1783]

I found this in my usenet archives about the evaluation order:

Quote

The order of side effects in sub-expressions is not consistent.
It may be changed in future. You should not write a code depending on it.

Yooichi Tagawa (Delphi Compiler R&D, Embarcadero)

Quote

Additionally, as the optimizer gets more sophisticated, the ordering
could further change depending on whether optimizations are on or off.

Allen Bauer
Embarcadero Chief Scientist

 

[Mark- 29]

4 hours ago, Anders Melander said:

I found this in my usenet archives about the evaluation order:

 

Thank you.

[corneliusdavid 214]

17 hours ago, David Heffernan said:

That just tells you about this one piece of code and whichever compilers you happened to use. It doesn't prove a rule. 

True. Somewhere back in time, I thought I had heard or read this and well, it made sense (to me) and a quick test of this one particular case in one particular version of Delphi confirmed my thinking but you're right, it certainly does not prove a rule. The much, MUCH better way is to just avoid writing obscure code in the first place. 

[Stefan Glienke 2002]

16 hours ago, Anders Melander said:

as the optimizer gets more sophisticated

And there I am, still hoping for that day to come