C# 中的按位运算
是否有更短、更好看的替代方案
(b == 0) ? 0 : 1;
就按位运算而言，
？另外，为了获得给定整数 a 的正确符号（-1、0 或 1），我当前正在使用
(a > 0) ? 1 : (a >> 32);
是否有更短（但不是更慢）的方法？
Is there a shorter and better-looking alternative to
(b == 0) ? 0 : 1;
in terms of bitwise operations?
Also, to get the correct sign (-1, 0 or 1) of a given integer a I am currently using
(a > 0) ? 1 : (a >> 32);
Are there any shorter (but not slower) ways?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
就我个人而言，我会坚持使用“等于或不等于零”选项的第一个选项。
对于整数的符号，我会使用 Math.Sign< /a> 并假设 JIT 编译器将内联它 - 如果结果证明它是潜在的瓶颈，则使用基准测试该假设。
首先考虑可读性——你的第一段代码非常明显。你的第二个不是。我什至不相信你的第二段代码有效...我认为右移被有效地屏蔽到了底部 5 位，假设这是一个
Int32（int）。编辑：刚刚检查过，实际上您当前的第二段代码相当于：
转变甚至没有出现在编译的代码中。
将此作为一个关于更多地关注微优化而不是可读性的实例课程。
如果代码易于理解，那么代码工作就会容易得多。如果你的代码给出了错误的结果，我不在乎它运行的速度有多快。
Personally I'd stick with the first option for your "equal to zero or not" option.
For the sign of an integer, I'd use Math.Sign and assume that the JIT compiler is going to inline it - testing that assumption with benchmarks if it turns out to be a potential bottleneck.
Think about the readability above all - your first piece of code is blindingly obvious. Your second isn't. I'm not even convinced your second piece of code works... I thought that right-shifts were effectively masked to the bottom 5 bits, assuming this is an
Int32(int).EDIT: Just checked, and indeed your current second piece of code is equivalent to:
The shift doesn't even end up in the compiled code.
Take this as an object lesson about caring more about micro-optimization than readability.
It's much easier to make code work if it's easy to understand. If your code gives the wrong result, I don't care how quickly it runs.
微优化是万恶之源。你为了一纳秒而牺牲了可读性。这是一笔糟糕的交易
Microoptimizations are the root of all evil. You sacrifice readability for a nanosecond. That's a bad bargain
Armen Tsirunyan 和 Jon Skeet 回答了您的技术问题，我将尝试解释您似乎存在的一些技术误解。
第一个错误是，如果您有一个 32 位有符号整数并尝试将其移位 32，那么您将尝试查看第 33 位，在有符号基数 2 算术的情况下，该位将是溢出位。
第二个错误是当您拥有 32 位有符号二进制值时。最后一位要么是一，要么是零。只有一个零值。因此，您试图找出符号是否为（-1,0,1）的陈述清楚地表明您不理解这个事实。如果有符号位是 1，则该数字将为负数，如果为 0，则该数字将为正数。 .NET Framework 中大部分处理数字的结构不知道 2 的补码和 1 的补码。当然，这并不意味着您不能扩展该功能或简单地将有符号整数转换为 2 的补码（老实说，非常简单）。
我应该补充一点，当你有一个有符号整数时，只有一个零值。我想这是我对你所做的“检查符号”声明的主要问题，它显示了对二进制数的误解。
http://en.wikipedia.org/wiki/Signed_magnitude#Sign-and-magnitude
Armen Tsirunyan and Jon Skeet answered your technical question, I am going to attempt to explain some technical misconceptions you appear to have.
The first mistake is that if you have a 32 bit signed integer and attempted to shift it by 32, you would be attempting to look at the 33rd bit which in the case of a signed base 2 arthmetic would be an overflow bit.
The second mistake is when you have 32-bit signed binary value. The last bit would either be a one or zero. There is a only a single zero value. So your statement of trying to figure out if the sign is ( -1,0,1) clearly indicates you don't understand this fact. If the signed bit is a 1 the number would be negative, if it was zero, it would be positive. The structures that handle a number for the most part within the .NET Framework are not aware of 2's complement and 1's complement. This of course does not mean you cannot extend that functionality or simply convert a signed integer to a 2's complement number ( really simple honestly ).
I should add that there is only one value for zero when you have a signed integer. I guess this is was my major problem with your "check the sign" statement that you made which shows a misconception about binary numbers.
http://en.wikipedia.org/wiki/Signed_magnitude#Sign-and-magnitude