Logic
-
Shameel wrote:
And in C# all logical operators always short-circuit.
You said all logical operators always short-circuit and that's not true.
&and|are logical operators and they don't short-circuit. I never said&can't be abitwise andbut in this case it is alogical and. -
So, in this case -
if (true & false)-&is not a logical AND? -
So, in this case -
if (true & false)-&is not a logical AND? -
Really? And I always thought that '&&' was simply a short-circuited '&'. I must go RTFM. :sigh:
As I have stated in my reply to Fabio,
&and&&are for different purpose.&is a bitwise operator and&&is a logical operator, they may produce same output in certain situations, but it does not mean that you can use them interchangeably. In C#, logical operators always short-circuit. See this link for an example: http://blog.dmbcllc.com/2009/03/16/vs-and-vs-whats-the-difference/[^] -
It is your mistake that you are using
&like a logical operator. It is NOT supposed to be used as a logical operator, we have&&for that purpose.Again, you're wrong, they are both logical operators in that case but one is short-circuited and the other is not! You have the same think in VB with the
And,AndAlso,Or,OrElseoperators, they are all handy in different situations. -
Again, you're wrong, they are both logical operators in that case but one is short-circuited and the other is not! You have the same think in VB with the
And,AndAlso,Or,OrElseoperators, they are all handy in different situations.Please read the msdn links that you posted, VB is different and C# is different. VB has two logical operators for AND operation,
Anddoes not short-circuit andAndAlsoshort-circuits. This is a design decision for backward compatibility with VB6. But C# was designed from the ground-up, so the designers were not constrained by the need to be backward compatible, they had more freedom which made them design&&to always short-circuit. Read this link which CLEARLY states that & and && are different: http://blog.dmbcllc.com/2009/03/16/vs-and-vs-whats-the-difference/[^] If you're still not convinced, then good luck to you, this is my last reply to this post. -
Please read the msdn links that you posted, VB is different and C# is different. VB has two logical operators for AND operation,
Anddoes not short-circuit andAndAlsoshort-circuits. This is a design decision for backward compatibility with VB6. But C# was designed from the ground-up, so the designers were not constrained by the need to be backward compatible, they had more freedom which made them design&&to always short-circuit. Read this link which CLEARLY states that & and && are different: http://blog.dmbcllc.com/2009/03/16/vs-and-vs-whats-the-difference/[^] If you're still not convinced, then good luck to you, this is my last reply to this post.What you don't seem to realise is that I'm not talking about the operators names but what they do. From MSDN[^]: & - logical AND | - logical OR && - conditional AND || - conditional OR From MSDN[^]: The operation
x && ycorresponds to the operationx & yexcept that if x is false, y is not evaluated (because the result of the AND operation is false no matter what the value of y may be). This is known as "short-circuit" evaluation. Which means I was right in my first post to say there was no difference, in that if condition, to use one or the other, the program still runs with no exceptions and as expected. Your only argument so far is that one is called logical and the other bitwise which doesn't change the fact that I was right; call them what you want. -
What you don't seem to realise is that I'm not talking about the operators names but what they do. From MSDN[^]: & - logical AND | - logical OR && - conditional AND || - conditional OR From MSDN[^]: The operation
x && ycorresponds to the operationx & yexcept that if x is false, y is not evaluated (because the result of the AND operation is false no matter what the value of y may be). This is known as "short-circuit" evaluation. Which means I was right in my first post to say there was no difference, in that if condition, to use one or the other, the program still runs with no exceptions and as expected. Your only argument so far is that one is called logical and the other bitwise which doesn't change the fact that I was right; call them what you want. -
This is true only in case where the operands of
&are bothbool, but unlike&&which takes onlybooloperands,&can also takeintas operands which can lead to unexpected behavior.And what's the case on the line of code in my first post?
-
This should really mess with your noggin:
bool isTrue = true || true && false; // True
bool isFalse = true | true && false; // False.Also, given your example, I'd prefer the double ampersand for 2 reasons: 1) for short-circuiting and 2) for standards' sake.
-
This should really mess with your noggin:
bool isTrue = true || true && false; // True
bool isFalse = true | true && false; // False.Also, given your example, I'd prefer the double ampersand for 2 reasons: 1) for short-circuiting and 2) for standards' sake.
I was just discussing the case that someone said that line was incorrect and downvoted my answer when in reality I just copied the OP's line and changed the = to == which is what was actually stopping it from working as expected. I prefer the double ampersand as well as a standard, the same way I always try to use short circuiting in VB which doesn't seem to be common practice, at least in online samples and articles.
-
And what's the case on the line of code in my first post?
-
In the case you have posted the final result would be the same as if you had used the && operator. There is, however, an important difference between & and &&. Have a look at this example:
ICollection col = null;
if (col != null && col.Count > 0)
// WhateverThis would first check this expression: col != null; like it is false and we are using && operator, it would not even try to check the second operand, becouse the final result will be false. However, if we use just the bitwise & operator:
ICollection col = null;
if (col != null & col.Count > 0)
// WhateverSince & operator is a bitwise operator it will try to check both operands so, in this case, it would throw a NullReferenceException when trying to evaluate the result of the second operand. That is why we always use the && operator in our boolean expressions, placing each operand in the right place. I guess this is what others have been trying to explain to you in this thread. That said, I would not have downvoted your answer just for this if the rest of the answer is correct, and I think that not being able to make you understand this is not reason enough to tell them to RTFM.
-
In the case you have posted the final result would be the same as if you had used the && operator. There is, however, an important difference between & and &&. Have a look at this example:
ICollection col = null;
if (col != null && col.Count > 0)
// WhateverThis would first check this expression: col != null; like it is false and we are using && operator, it would not even try to check the second operand, becouse the final result will be false. However, if we use just the bitwise & operator:
ICollection col = null;
if (col != null & col.Count > 0)
// WhateverSince & operator is a bitwise operator it will try to check both operands so, in this case, it would throw a NullReferenceException when trying to evaluate the result of the second operand. That is why we always use the && operator in our boolean expressions, placing each operand in the right place. I guess this is what others have been trying to explain to you in this thread. That said, I would not have downvoted your answer just for this if the rest of the answer is correct, and I think that not being able to make you understand this is not reason enough to tell them to RTFM.
Again, what makes you think I don't know the difference between & and &&?! I never said they do the same thing and I do know that && is the most commonly used. That, however, does not make it wrong to use & between two boolean and it does not invalidate the fact that in that case it makes no difference. And if someone says it does then they should RTFM!
-
Again, what makes you think I don't know the difference between & and &&?! I never said they do the same thing and I do know that && is the most commonly used. That, however, does not make it wrong to use & between two boolean and it does not invalidate the fact that in that case it makes no difference. And if someone says it does then they should RTFM!
Fabio V Silva wrote:
what makes you think I don't know the difference between & and &&?!
Oh, nothing at all but, you know, this is a public forum, and although there are many posts in this thread none of them was giving a good explanation about the differencies between those operators, becouse there are differencies, I know them, you know them and I know you know them, but a beginner might get confused after reading this thread. That's all.
-
So, are you saying you can't use
&in that case?! They do the same except for the fact that && is short-circuited.Fabio V Silva wrote:
They do the same except for the fact that && is short-circuited.
Except they don't do they? For boolean operands they do the same thing, (ignoring, as you said, the short circuiting which is a very good reason to use
&&). Take this example:Console.WriteLine( 42 && 3);
Syntax error. Why? Because it is a Logical Operator which takes booleans as its operands. Now take:
Console.WriteLine( 42 & 3)</pre>
Answer 2: Why? Because it is a Bitwise Logical Operator (though most people drop the "Logical") ANDing on the bits:101010 AND
000011000010
= 2.
The bitwise
|and&operators are best left for work at the bit-level (such as bit-masking), whereas the the C# logical operators are better suited to boolean comparisons, like in the OP.I wouldn't have voted you down BTW, but I would have pointed it out.
Sort of a cross between Lawrence of Arabia and Dilbert.[^]
-Or-
A Dead ringer for Kate Winslett[^] -
Again, what makes you think I don't know the difference between & and &&?! I never said they do the same thing and I do know that && is the most commonly used. That, however, does not make it wrong to use & between two boolean and it does not invalidate the fact that in that case it makes no difference. And if someone says it does then they should RTFM!
-
Really? And I always thought that '&&' was simply a short-circuited '&'. I must go RTFM. :sigh:
Ha, that's what they taught me as well. It's utter nonsense off course since both '&' and '|' would be completely useless if that was the only difference. It's just that it's a good habit to always use '&&' and '||' unless you need '&' or '|' specifically, even in cases where the result is the same.
-
As I have stated in my reply to Fabio,
&and&&are for different purpose.&is a bitwise operator and&&is a logical operator, they may produce same output in certain situations, but it does not mean that you can use them interchangeably. In C#, logical operators always short-circuit. See this link for an example: http://blog.dmbcllc.com/2009/03/16/vs-and-vs-whats-the-difference/[^]The
&&operator should be used instead of the&operator for clarity's sake because its the standard way of doing things. Also the&&operator gives you some type safety that the&operator does not when dealing with LOGICAL ANDS:(4 && 5)will not compile but(4 & 5)will. If you are intending to perform a LOGICAL AND operation you could end up performing a LOGICAL BITWISE AND operation instead by mistake. But in any case, the reason you are giving: "(...)In C#, logical operators always short-circuit(...) is so wrong I dont even know where to begin. The operator&is an overloadable operator. Integral and boolean types have their own predefined&binary operators:&(int, int)computes the logical bitwise AND of its operands while&(bool, bool)computes the logical AND of its operands; that is, the result is true if and only if both its operands are true. This is all straight from the C# specifications:http://msdn.microsoft.com/en-us/library/sbf85k1c.aspx[^] Sobool & boolis NOT A BITWISE OPERATION at all. Its a normal LOGICAL AND OPERATION where both terms are always evaluated contrary tobool && boolwhere the second term is evaluated if and only if the first term is true.modified on Thursday, May 19, 2011 5:55 AM
-