<p>Am 03.02.2016 12:11 schrieb "Serguei TARASSOV" <<a href="mailto:serge@arbinada.com">serge@arbinada.com</a>>:<br>
><br>
> On 03/02/2016 12:00, <a href="mailto:fpc-pascal-request@lists.freepascal.org">fpc-pascal-request@lists.freepascal.org</a> wrote:<br>
>><br>
>> Date: Tue, 2 Feb 2016 19:43:02 -0700 (MST)<br>
>> From: silvioprog<<a href="mailto:silvioprog@gmail.com">silvioprog@gmail.com</a>><br>
>><br>
>><br>
>>> >The problem with Iff() is:1) it either retains normal function behavior<br>
>>> >and thus has to evaluate both expressions (i.e. suboptimal performance and<br>
>>> >allowing side effects);<br>
>><br>
>> Well:<br>
>> program Project1;  function test1: integer;  begin    WriteLn('A');<br>
>> Result := 10;  end;  function test2: integer;  begin    WriteLn('B');<br>
>> Result := 20;  end;  function CommonFunc(A: Boolean; B, C: integer):<br>
>> integer;  begin    if A then      Result := B    else      Result := C;<br>
>> end;var  X: LongInt;begin  X := IfThen(True, test1, test2);  WriteLn(X);<br>
>> WriteLn('----');  X := CommonFunc(True, test1, test2);  WriteLn(X);<br>
>> ReadLn;end.<br>
>> Result:<br>
>> A10----BA10<br>
><br>
> Holy sh*t, ça continue ! :)<br>
> Even if evaluation order will be assured and well documented, it doesn't make sense!<br>
> Example :<br>
><br>
> x := iif(Obj = nil, 0, Obj.Value); // Seems OK when right-to-left and stop on 'true' evalation<br>
> x := iif(Obj <> nil, Obj.Value, 0); // Raise access violation</p>
<p>The current IfThen() intrinsic is not a function call. Internally it gets replaced by an if-node thus from the compiler's point of view it behaves like an if-statement that assigns the expressions in its branches to a temporary variable (yes that one is thrown away during code generation...), thus the term evaluation order in the sense of calling functions does not apply at all anyway.</p>
<p>Regards,<br>
Sven</p>