ordering of IF-statement conditions

[ThermoSight]

Hello again.

Say, I wonder if anyone can tell me whether there is a definition of the order of evaluation of IF statement conditions in C#.

For instance, in the statement ...

if ( (delayInSecs == 0) || (--delayInSecs == 0)) {
doSomething();
}

does the C# compiler guarantee that 'delayInSecs' will never go negative as a result of evaluating that IF statement ?

Certainly I could just try it an see what happens, but that wouldn't tell me that the compiler guarantees that action, only that in this case the compiler did this or that.

Thanks for your help.

bill

[monalin]

The if statement you have doesn't guarantee anything.

You want doSomething() to run when delayInSecs is a positive number?

if((delayInSecs >= 0)
    doSomething();

I'm defiantly confused by your question though.

[ThermoSight]

Hi Monalin,

Thanks so much for your help with this.

I've probably just embarrassed myself by revealing my ignorance to all, but I thought that the
statement ....

if ( (delayInSecs == 0) || (--delayInSecs == 0))
doSomething();


would 'doSomething()' if 'delayInsecs' was ALREADY set to 0, or if decrementing it caused it to reach zero. That PRESUMES left-to-right evaluation ordering.

What I had HOPED to prevent was having the compiler evaluate the right-hand condition first WHEN 'delayInSecs' IS ALREADY ZERO, thus causing 'delayInSecs' to go negative.

Because I read left-to-right, I automatically assume the compiler will operate in a similar fashion, but I wondered if there was a compiler requirement to do so. I seem to recall, For instance, that Ada GUARANTEES a left-to-right evaluation ordering, whereas (I'm told) FORTRAN did not.



Perhaps I can clarify the example ....

if ( (delayInSecs == 0) || (--delayInSecs == 0)) {
if (!Lisp)
do Something();
}


now again, at risk of embarrassing myself by exposing my ignorance, it seems possible that if 'delayinsecs' is 1 when the IF statement is encountered, it is decremented to zero, satisfying the condition, BUT if Lisp is true, we don't do something.

At the next second, if the compiler guarantees left-to-right evaluation, 'delayInSecs' will still be zero, list processing has been completed so Lisp is no longer true, and we go on to doSomething().

BUT, if there is no such left-to-right evaluation guarantee, then the compiler is free to evaluate the right-hand condition first, decrementing 'delayInSecs' to -1 or 2^32-1. Either way, it'll be awhile before we doSomething().


I dunno; it's very likely that I'm wrong (AGAIN!) but that's what I had in mind. Thank you so much for taking the time to help me.

Best wishes.

bill

[Arjay]

Thermosight, why not code it up so that you don't have to rely on the evaluation ordering?

[monalin]

You can assume that the compiler will evaluate the conditions from left to right.

When coding i find myself doing something like this all the time. For example.

if(obj != null && obj.Value == 0)

If it didn't always check left to right and obj was null then it would throw an exception. However the compiler evaluates these conditions from left to right and as soon as a condition fails it stops and moves on.

If obj was null here in my example, it would never check obj.Value == 0 because it knows that no matter what the rest of the conditions are it cannot be true.

In your situation if delayInSecs == 0 it would never check --delayInSecs == 0 because the first statement satisfied the if condition it has no need to check the second one thus delayInSecs stays at 0 and will not become negative.

[Arjay]

Keep in mind that the OP has an OR condition, not an AND condition.

With OR, won't both be evaluated?

[ThermoSight]

Gentlemen, Hello !


Arjay - thank you for your comment, Sir. Actually, until a very few minutes ago, it was coded as you've suggested, but it occurred to me that I could make the code more concise by combining the two IF statements; and if the code is more concise, it's more easily understood by those that follow.

This code segment is part of a timer service routine called once each second. Now, normally I want to "doSomething" when the 'delayInSecs' reaches zero, but occasionally I am blocked from "doing something" because of an action taken by others, and so I defer "doSomething" for (hopefully) a second or two (hence the 'Lisp' test). I can defer up to 15 seconds before I must begin dropping events (and excoriate the user).

In the interim between replies, I have recoded the IF statement(s), combining the two into one. I then looked at the assembly code and found that it's doing what I hoped for, left-to-right evaluation (and the program still works although from a test perspective, that proves nothing). However, without an Ada-like guarantee, it seems to this OldFool that there's no guarantee that a similar statement elsewhere would always work as intended.

Incidentally, Arjay, your name sounds very familiar ... I think we've spoken before .... I'm bill from Mercer Island. How's it goin' Arjay ?

Monalin, Hello .... yes indeed, that's EXACTLY what I had in mind .... you were lightyears ahead of me, my friend. I just wondered if there was a guarantee somewhere in C#, or if it just happened to work serendipitously, but could not be relied on. Apparently you have determined that such behavior CAN be relied upon.

Does Microsoft maintain a document which spells out in great detail how each statement is rendered by the compiler .... a GUARANTEE that an accredited C# compiler will always behave in a certain manner when encountering a particular statement ?


Gentlemen, thanks so much for your help. Very much appreciated.

Best wishes.

bill

[rliq]

if() statements are evaluated from left to right in C#. As soon as one condition meets the requirements, non of the remaining conditions will be evaluated. Eg:

a = 0;
// succeeds on first condition
if (a.Equals(0) || (--x < 50) || (y += 23) > MyFunc(--x) || etc etc)
{
    // This bit gets executed, but x and y do *not* get changed
}

a = 12;
// fails on first condition
if (a.Equals(0) && (--x < 50) && (y += 23) > MyFunc(--x) && etc etc)
{
    // This bit does *not* get executed and x and y do not get changed
}

In VB (Visual Basic), which is to coding, what VB (Victoria Beer) is to beer, the order cannot be guaranteed (at least in VB6.0), assume VB.NET too.