为什么C＃中的32位移位会返回原来移位的值？

问题描述

我只是想澄清一下C＃的移位。

当我将UINT32的位向右移动32时，我得到的值向后移动。我的预期结果是将值归零00000000

例如：

System.Diagnostics.Debug.WriteLine((Convert.ToUInt32("FFFFFFFF",16) >> 8).ToString("X8"));
System.Diagnostics.Debug.WriteLine((Convert.ToUInt32("FFFFFFFF",16) >> 16).ToString("X8"));
System.Diagnostics.Debug.WriteLine((Convert.ToUInt32("FFFFFFFF",16) >> 24).ToString("X8"));
System.Diagnostics.Debug.WriteLine((Convert.ToUInt32("FFFFFFFF",16) >> 32).ToString("X8"));

System.Diagnostics.Debug.WriteLine((Convert.ToUInt32("FF",16) >> 8).ToString("X"));
System.Diagnostics.Debug.WriteLine((Convert.ToUInt32("FFFF",16) >> 16).ToString("X"));
System.Diagnostics.Debug.WriteLine((Convert.ToUInt32("FFFFFF",16) >> 24).ToString("X"));
System.Diagnostics.Debug.WriteLine((Convert.ToUInt32("FFFFFFFF",16) >> 32).ToString("X"));

生产

00FFFFFF
0000FFFF
000000FF
FFFFFFFF

0
0
0
FFFFFFFF

有人可以解释为什么会这样吗？

解决方法

这是一个预期的并得到记录的行为-当计数为32个移位（对于int / uint）实际上为0移位时，因为仅考虑了5个低位（32 & 0x1f为0 ）：

Bitwise and shift operators (C# reference): Shift count of the shift operators

如果x的类型为int或uint，则移位计数由右侧操作数的低5位定义。也就是说，移位计数是根据count＆0x1F（或count＆0b_1_1111）计算的。

根据评论，您的实际问题似乎是“为什么C＃设计人员决定以这种方式定义它，而不是其他某种或更好的方法，但仍坚持类似于C / C ++的未定义行为”，这实际上是基于观点的（除非存在一些官方设计文件保存了特定的讨论和决定）：

尽管UB可能允许对结果代码进行一些其他优化或简化编译器，但它也导致代码在与其他编译器一起使用时可能会完全改变其行为。通常，您可能会发现C＃和.Net优于万无一失的正确性，而不是潜在的性能提升。另一方面，C / C ++依赖于对语言边界有深入了解的开发人员来生成在所有编译器上都可以运行的代码。

关于为什么选择特定行为-使用哪种特定选择来定义行为几乎无关紧要，因为对于任何特定的未定义行为，不同的编译器/处理器具有不同的首选结果。

其他考虑因素是易于记录-类似于“如果第16位为0，移位超过31（对于有符号），而32（无符号）产生01，则重复16次，否则为负1表示负零。未签名的，除非计数大于42，则...”

bit-shift c#c#operators operators