Multiple Conditions Firing order

[TheLostLeaf]

Hi,

Does anyone know if these 2 code segments would operate the same way.



for instance if the first condition fails does it bother to check the
second?

if (MyList.Count > 0 && CheckDate) {

// do something...

}

or

if(MyList.Count)
{
if(CheckDate)
{
// do something...
}
}

public bool CheckDate()
{
return true;
}

 

[craig.wenger]

In C#, like C, logic is short-circuiting. So when you have if(a && b)
it will only check b if a is true, and when you have if(a || b) it
will only check b if a is NOT true; otherwise it will return after
checking a. That's why you can get away with if(object != null &&
object.Property == something). In VB, the And and Or logic is NOT
short-circuting, you have to use AndAlso and OrElse for this.

With that said, I would assume the two are equivalent but there could
be a subtle difference, I will defer to somebody else on that.

 

[TheLostLeaf]

Thanks !

I wanted to double check, but that makes sense. Less code is always
nicer to get the same result.

 

[Jon Skeet [C# MVP]]

Thanks !

I wanted to double check, but that makes sense. Less code is always
nicer to get the same result.

Note that only && and || are short-circuiting. If you change your
condition to

if (MyList.Count > 0 & CheckDate)

it will always test both conditions.

 

[Peter Duniho]

Note that only && and || are short-circuiting. If you change your
condition to

if (MyList.Count > 0 & CheckDate)

it will always test both conditions.

Can you clarify? I only see one condition in that clause.

Pete

 

[Jon Skeet [C# MVP]]

Can you clarify? I only see one condition in that clause.

MyList.Count and CheckDate will both be evaluated in the above,
whereas the version with && won't evaluate CheckDate if MyList.Count
isn't positive.

Jon

 

[mpetrotta]

Can you clarify? I only see one condition in that clause.

The binary '&' operator serves two masters. From MSDN:

Binary & operators are predefined for the integral types and bool. For
integral types, & computes the logical bitwise AND of its operands.
For bool operands, & computes the logical AND of its operands; that
is, the result is true if and only if both its operands are true.

Since '0' and 'CheckDate' don't have matching types, this ambiguity
isn't an issue in the expression above.

Michael

 

[Peter Duniho]

MyList.Count and CheckDate will both be evaluated in the above,
whereas the version with && won't evaluate CheckDate if MyList.Count
isn't positive.

But there's still only one condition. That is, there is no conditional
operator, so the entire clause is a single condition. In that situation,
it should be no surprise that everything gets evaluated, because there's
nothing to short-circuit.

Or was that your point?

FWIW, I found the statement "it will always test both conditions"
confusing, because of the fact that there is just the single condition in
the example.

Pete

 

[Peter Duniho]

The binary '&' operator serves two masters. From MSDN:

Binary & operators are predefined for the integral types and bool. For
integral types, & computes the logical bitwise AND of its operands.
For bool operands, & computes the logical AND of its operands; that
is, the result is true if and only if both its operands are true.

Since '0' and 'CheckDate' don't have matching types, this ambiguity
isn't an issue in the expression above.

The relational > operator has higher precedence than the logical &
operator, so both operands of the & operator are boolean, and so the
so-called ambiguity would in fact be an issue, if it existed.
"MyList.Count > 0" is evaluated before the rest of the clause.

However, I don't see it as an ambiguity anyway. The logical & operator
does the same thing with two booleans that it would do with two ints. It
just doesn't bother to promote the result to an int. The behavior doesn't
really change depending on the type, any more than the * operator's
behavior changes according to operand type (use * with two ints, you get
an int, use it with two longs, you get a long).

But the & operator is not a conditional operator, and since one should
expect only a conditional operator to short-circuit, I don't find the lack
of short-circuiting surprising at all.

C/C++ works in exactly the same way. It has the same logical & operator,
and that operator always requires both of its operands to be evaluated.

Pete

 

[mpetrotta]

The relational > operator has higher precedence than the logical &
operator, so both operands of the & operator are boolean, and so the
so-called ambiguity would in fact be an issue, if it existed.
"MyList.Count > 0" is evaluated before the rest of the clause.

However, I don't see it as an ambiguity anyway. The logical & operator
does the same thing with two booleans that it would do with two ints. It
just doesn't bother to promote the result to an int. The behavior doesn't
really change depending on the type, any more than the * operator's
behavior changes according to operand type (use * with two ints, you get
an int, use it with two longs, you get a long).

But the & operator is not a conditional operator, and since one should
expect only a conditional operator to short-circuit, I don't find the lack
of short-circuiting surprising at all.

C/C++ works in exactly the same way. It has the same logical & operator,
and that operator always requires both of its operands to be evaluated.

Peter, I was talking about ambiguity reading the code. I'm aware that
C#'s operator precedence rules are well defined. It seemed to me,
though, that the OP didn't understand the relative precedence of '>'
and '&' (and I confess that I'd need to look up the order of '|' and
'^', for instance).

Parentheses are cheap. There's no reason to go with
if (x || y && z)
when you could use
if (x || (y && z))

Michael

 

[Peter Duniho]

[...]
Parentheses are cheap. There's no reason to go with
if (x || y && z)
when you could use
if (x || (y && z))

I agree...I very often use parentheses when not needed, simply because it
enhances the readability of the code.

Operator precedence is important for the sake of having a language
well-defined, but I prefer to make things explicit except in the simplest
cases.

Pete

 

[Jon Skeet [C# MVP]]

But there's still only one condition. That is, there is no conditional
operator, so the entire clause is a single condition. In that situation,
it should be no surprise that everything gets evaluated, because there's
nothing to short-circuit.

Or was that your point?

FWIW, I found the statement "it will always test both conditions"
confusing, because of the fact that there is just the single condition in
the example.

I was trying to use the same terminology as the OP. If we're going to
use spec terminology, && is a "conditional logical operator" and I
don't think the spec defines "condition" at all.

My sole point was that && behaves differently to &. Yes, many people
would expect that without being told - but it wasn't clear whether the
OP would know it, so I pointed it out. As the OP was calling the two
boolean sub-expressions "conditions" I decided to follow suit.

 

[Jon Skeet [C# MVP]]

[...]
Parentheses are cheap. There's no reason to go with
if (x || y && z)
when you could use
if (x || (y && z))

I agree...I very often use parentheses when not needed, simply because it
enhances the readability of the code.

Operator precedence is important for the sake of having a language
well-defined, but I prefer to make things explicit except in the simplest
cases.

Absolutely. I've very deliberately not learned the precedence of
operators (beyond "a*b + c" etc) so that I won't be able to assume that
anyone else has either

 

[Peter Duniho]

I was trying to use the same terminology as the OP. [...]

As the OP was calling the two
boolean sub-expressions "conditions" I decided to follow suit.

I see...fair enough.