C#中的逻辑与条件逻辑运算符 [英] Logical vs. Conditional Logical Operators in C#

查看:248
本文介绍了C#中的逻辑与条件逻辑运算符的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

大家好,


我和同事讨论过&b $&b;和&&运算符应用于C#中的布尔操作数。他的b $ b b观点是表达式(false& expr2)可能在JIT时间优化了
,而第二个表达式将不会被评估。在我的

意见中,如果JIT

编译器完全删除对expr2的调用,这将破坏C#语言的契约。我不是说

依靠expr2'

评估的副作用是一个很好的编程习惯,我只是说它只是感觉_right_知道

逻辑表达式的两面都被评估了。


我真的很感激来自CLR的一些输入那里的大师。

IL中这些运算符之间有区别吗?可能是JIT

编译器可以简化评估的快捷方式吗?我错过了什么其他的东西?


谢谢,


Jono

Hi all,

I''m having an argument with a co-worker about the difference between
the & and && operators when applied to boolean operands in C#. His
point of view is that the expression (false & expr2) might be optimised
at JIT-time and the second expression will not be evaluated. In my
opinion this would break the contract of the C# language if the JIT
compiler were to remove the call to expr2 entirely. I''m not saying that
it''s good programming practice to depend on the side effects of expr2''s
evaluation, all I''m saying is that it just feels _right_ to know that
both sides of the logical expression were evaluated.

I''d really appreciate any input from some of the CLR gurus out there.
Is there a difference between these operators in IL? Might a JIT
compiler conceivably shortcut the evaluation? Any other things I
missed?

Thanks,

Jono

推荐答案

使用&&运算符编译器使用短路逻辑,例如,第一个oparand为假,第二个不被评估。这可以在以下语句中使用




if(str!= null&& str.Length!= 0)...


这是安全的,因为第二个操作数没有被评估它的参考是

null。如果两个操作数都被评估,那么第二个将抛出一个

NullReferenceException如果引用为null。


当使用&运算符,两个操作数总是被评估。

Jonathan写道:
When using the && operator the compilier uses short circuit logic, e.g.
it the first oparand is false, the second one is not evaluated. This can
be used in statements like:

if (str != null && str.Length != 0) ...

This is safe, as the second operand is not evaluated it the reference is
null. If both operands were evaluated, the second would throw an
NullReferenceException if the reference was null.

When using the & operator, both operands are always evaluated.
Jonathan wrote:
大家好,

我正在与同事争吵关于
&的区别和&&运算符应用于C#中的布尔操作数。他的观点是,表达式(false& expr2)可能在JIT时被优化,而第二个表达式将不会被评估。在我的意见中,如果JIT
编译器完全删除对expr2的调用,这将破坏C#语言的契约。我不是说依赖于expr2评估的副作用是一种很好的编程习惯,我只是说它只是觉得_right_才知道
对逻辑表达式的两个方面进行了评估。

我非常感谢那里的一些CLR大师的任何意见。
这些运营商之间是否存在差异IL?可能是JIT
编译器可以简化评估的快捷方式吗?我还错过了其他任何事情吗?

谢谢,

Jono
Hi all,

I''m having an argument with a co-worker about the difference between
the & and && operators when applied to boolean operands in C#. His
point of view is that the expression (false & expr2) might be optimised
at JIT-time and the second expression will not be evaluated. In my
opinion this would break the contract of the C# language if the JIT
compiler were to remove the call to expr2 entirely. I''m not saying that
it''s good programming practice to depend on the side effects of expr2''s
evaluation, all I''m saying is that it just feels _right_ to know that
both sides of the logical expression were evaluated.

I''d really appreciate any input from some of the CLR gurus out there.
Is there a difference between these operators in IL? Might a JIT
compiler conceivably shortcut the evaluation? Any other things I
missed?

Thanks,

Jono



Jonathan< ;乔******* @ gmail.com>写道:
Jonathan <jo*******@gmail.com> wrote:
我正在与同事讨论
&和&&运算符应用于C#中的布尔操作数。他的观点是,表达式(false& expr2)可能在JIT时被优化,而第二个表达式将不会被评估。在我的意见中,如果JIT
编译器完全删除对expr2的调用,这将破坏C#语言的契约。我不是说依赖于expr2评估的副作用是一种很好的编程习惯,我只是说它只是觉得_right_才知道
对逻辑表达式的两个方面进行了评估。

我非常感谢那里的一些CLR大师的任何意见。
这些运营商之间是否存在差异IL?可能是JIT
编译器可以简化评估的快捷方式吗?我错过了什么其他的事情?
I''m having an argument with a co-worker about the difference between
the & and && operators when applied to boolean operands in C#. His
point of view is that the expression (false & expr2) might be optimised
at JIT-time and the second expression will not be evaluated. In my
opinion this would break the contract of the C# language if the JIT
compiler were to remove the call to expr2 entirely. I''m not saying that
it''s good programming practice to depend on the side effects of expr2''s
evaluation, all I''m saying is that it just feels _right_ to know that
both sides of the logical expression were evaluated.

I''d really appreciate any input from some of the CLR gurus out there.
Is there a difference between these operators in IL? Might a JIT
compiler conceivably shortcut the evaluation? Any other things I
missed?




双方都用& ;.评估。正如你所说,只评估一方

将打破语言规范。 (如果JIT注意到它完全没有副作用,那么可以做一些优化 - 但是

你必须查看生成的代码要确定无疑。)


使用&&,保证如果LHS是
,RHS将不会被评估false。


这个(及其等价的或)允许这样的事情:


if(x == null || x.Length == 0)


是安全的。


-

Jon Skeet - < sk***@pobox.com>
http://www.pobox。 com / ~siget 博客: http://www.msmvps.com/ jon.skeet

如果回复小组,请不要给我发邮件



Both sides are evaluated with &. As you say, only evaluating one side
would be breaking the language spec. (If the JIT notices that it''s
completely without side-effects, it could do some optimisation - but
you''d have to look at the generated code to know for sure.)

With &&, it''s guaranteed that the RHS won''t be evaluated if the LHS is
false.

This (and its equivalent for "or") allows for things like:

if (x==null || x.Length==0)

to be safe.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too


这是另一种方式。


false&&保证expr2永远不会评估expr2,就像

true ||一样expr2保证永远不会评估expr2。





false& expr2保证始终评估expr2,就像

true | expr2保证始终评估expr2。


&&和||运营商被称为使用McCarthy评估

(对于我们的老年人)或更近期的短路评估。评价。在

一般&&和||表格是首选,并且常见的C,C ++和

C#成语如下:


if(myObject!= null&& myObject.BoolProperty)

{

...做点什么...

}

It''s the other way around.

false && expr2 is guaranteed never to evaluate expr2, just as
true || expr2 is guaranteed never to evaluate expr2.

whereas

false & expr2 is guaranteed to always evaluate expr2, just as
true | expr2 is guaranteed always to evaluate expr2.

The && and || operators are referred to as using McCarthy evaluation
(for us old-timers) or more recently "short-circuit" evaluation. In
general the && and || forms are preferred, and it is common C, C++, and
C# idiom to say things like:

if (myObject != null && myObject.BoolProperty)
{
... do something ...
}


这篇关于C#中的逻辑与条件逻辑运算符的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆