On 04/02/2016 12:00, fpc-pascal-requ...@lists.freepascal.org wrote:
Date: Wed, 3 Feb 2016 14:34:34 +0100
From: Sven Barth<pascaldra...@googlemail.com>

Am 03.02.2016 12:11 schrieb "Serguei TARASSOV"<se...@arbinada.com>:
>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.

I see, and it is what I said many times: you wrap the if-statement into pseudo-function.
This make no sense and will be source of programmer's errors.
The simplest case is to add "uses Math" or "uses StrUtils" to hide intrinsic pseudo-function and crash the application.

iif bool-expression then expression-true else expression-false;
or
inline if bool-expression then expression-true else expression-false;

is only solution in my opinion.

Regards,
Serguei
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Reply via email to