Board index » delphi » Unexpected IF behaviour

Unexpected IF behaviour

I had a piece of code,

if (not VarIsNull (myTable [fieldName])) and myTable [fieldName] . . .

which compiles but generates an 'Invalid Variant Type Conversion' error.
Complete Boolean Evaluation is off. None the less it did seem to be
executing code generated for the term following the AND even when the first
term is false. Interestingly the following code did not generate the error
and produced the expected results.

if (not VarIsNull (myTable [fieldName])) and Boolean (myTable [fieldName]) .
. .

I went on to try

if (not VarIsNull (aVariant)) and functionReturningAVariant . . .

the functionReturningAVariant is always called when the IF above executes,
regardless of the value of aVariant. However, it is not called when the
first term is null in the following statement

if (not VarIsNull (aVariant)) and Boolean (functionReturningAVariant) . . .

It does seem to me that this is an inconsistency. Is there an explanation
for the behavior?

 

Re:Unexpected IF behaviour


All of this with "Complete Boolean Evaluation" off? Seems to me that
having "Complete Boolean Evaluation" is *asking* for inconsistency. I
don't see anywhere that the order in which the operands are evaluated
is defined (ie left to right as you presumed). I'd bet that ye old
optimizing compiler has something to do with it though.

Scott

Quote
Bruce Roberts wrote in message ...
>I had a piece of code,

>if (not VarIsNull (myTable [fieldName])) and myTable [fieldName] . .
.

>which compiles but generates an 'Invalid Variant Type Conversion'
error.
>Complete Boolean Evaluation is off. None the less it did seem to be
>executing code generated for the term following the AND even when the
first
>term is false. Interestingly the following code did not generate the
error
>and produced the expected results.

>if (not VarIsNull (myTable [fieldName])) and Boolean (myTable
[fieldName]) .
>. .

>I went on to try

>if (not VarIsNull (aVariant)) and functionReturningAVariant . . .

>the functionReturningAVariant is always called when the IF above
executes,
>regardless of the value of aVariant. However, it is not called when
the
>first term is null in the following statement

>if (not VarIsNull (aVariant)) and Boolean (functionReturningAVariant)
. . .

>It does seem to me that this is an inconsistency. Is there an
explanation
>for the behavior?

Re:Unexpected IF behaviour


On Wed, 17 Mar 1999 16:56:26 -0500, "Bruce Roberts" <b...@attcanada.net>
wrote:

Quote
>I had a piece of code,

>if (not VarIsNull (myTable [fieldName])) and myTable [fieldName] . . .

>which compiles but generates an 'Invalid Variant Type Conversion' error.
>Complete Boolean Evaluation is off. None the less it did seem to be
>executing code generated for the term following the AND even when the first
>term is false. Interestingly the following code did not generate the error
>and produced the expected results.

>if (not VarIsNull (myTable [fieldName])) and Boolean (myTable [fieldName]) .
>. .

>I went on to try

>if (not VarIsNull (aVariant)) and functionReturningAVariant . . .

>the functionReturningAVariant is always called when the IF above executes,
>regardless of the value of aVariant. However, it is not called when the
>first term is null in the following statement

>if (not VarIsNull (aVariant)) and Boolean (functionReturningAVariant) . . .

>It does seem to me that this is an inconsistency. Is there an explanation
>for the behavior?

The problem here is that the variant-ness of the second operand
overrides the Boolean-ness of the first.  The rules for operations
involving variants say that the two operands are converted to a common
type, but the compiler can't know the common type until run time, after
it has evaluated both operands.  If the second operand turned out to be
an integer (varInteger), it would convert the first to integer as well,
and perform a bitwise rather than logical 'and'.

Oddly, this partial statement doesn't evaluate the second operand:

  if false and FunctionReturningVariant ...

but this seems to be an inconsistency on the part of the compiler, as by
its own rules it should evaluate both.

--
"Oh, shootings.  Yes, but that doesn't mean Americans are more {*word*268}
than other people.  We're just better shots."

Re:Unexpected IF behaviour


Quote
>The problem here is that the variant-ness of the second operand
>overrides the Boolean-ness of the first.

And what overrides Elliot Ness? :)

Good Luck!!
    -Dave
Inprise Certified Delphi 4 Client/Server developer
http://www.erols.com/dparsons

Re:Unexpected IF behaviour


Quote
Dave Parsons wrote:
> >The problem here is that the variant-ness of the second operand
> >overrides the Boolean-ness of the first.

> And what overrides Elliot Ness? :)

His tombstone.

Re:Unexpected IF behaviour


Quote
>Oddly, this partial statement doesn't evaluate the second operand:

>  if false and FunctionReturningVariant ...

>but this seems to be an inconsistency on the part of the compiler, as by
>its own rules it should evaluate both.

Actually,

if False and anythingelse then

need not evaluate the anythingelse part, because the result of the if test
will always be false.

Christopher Latta

Re:Unexpected IF behaviour


Im Artikel <ee7uVFMc#GA.183@upnetnews05>, "Bruce Roberts" <b...@attcanada.net>
schreibt:

Quote
>It does seem to me that this is an inconsistency. Is there an explanation
>for the behavior?

It's somewhat consistent, with regards to the difference between logic and
arithmetic operators. In your case the right operand of "and" is not boolean,
forcing an arithmetic (bitwise) operation to occur. The compiler seems to
optimize only logical expressions, as you already found out yourself.

IMO it would always be cleaner to separate such mixed conditions into nested
IF's, also with regards to the many parentheses.

DoDi

Re:Unexpected IF behaviour


I've been going through the help on variants, again, and I did come across
the following:

"Also for all non-relational operators, if one or both operands are Null ,
the result of the operation is Null. In other words, Null values propagate
through expressions, and the presence of a Null value in an expression
causes the entire expression to become Null."

This implies that
    a) the behaviour I noted is as designed
    b) the behaviour that David noted is not as designed (if false and
variantFunction)

Other Threads