[fpc-pascal] if-then-else expression

[Sven Barth]

Am 03.02.2016 12:11 schrieb "Serguei TARASSOV" <serge at arbinada.com>:
>
> On 03/02/2016 12:00, fpc-pascal-request at lists.freepascal.org wrote:
>>
>> Date: Tue, 2 Feb 2016 19:43:02 -0700 (MST)
>> From: silvioprog<silvioprog at gmail.com>
>>
>>
>>> >The problem with Iff() is:1) it either retains normal function behavior
>>> >and thus has to evaluate both expressions (i.e. suboptimal performance
and
>>> >allowing side effects);
>>
>> Well:
>> program Project1;  function test1: integer;  begin    WriteLn('A');
>> Result := 10;  end;  function test2: integer;  begin    WriteLn('B');
>> Result := 20;  end;  function CommonFunc(A: Boolean; B, C: integer):
>> integer;  begin    if A then      Result := B    else      Result := C;
>> end;var  X: LongInt;begin  X := IfThen(True, test1, test2);  WriteLn(X);
>> WriteLn('----');  X := CommonFunc(True, test1, test2);  WriteLn(X);
>> ReadLn;end.
>> Result:
>> A10----BA10
>
> Holy sh*t, ça continue ! :)
> Even if evaluation order will be assured and well documented, it doesn't
make sense!
> Example :
>
> x := iif(Obj = nil, 0, Obj.Value); // Seems OK when right-to-left and
stop on 'true' evalation
> x := iif(Obj <> nil, Obj.Value, 0); // Raise access violation

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.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20160203/ecc4e783/attachment.html>