Mod 2, test for = 1。不知道c中的语法，但这可能是最快的。

我同意其他答案，你应该支持x / 2，因为它的意图更清楚，编译器应该为你优化它。

然而，选择x / 2而不是x >> 1的另一个原因是，如果x是一个有符号int并且是负的，那么>>的行为是依赖于实现的。

ISO C99标准第6.5.7节第5项:

E1 >> E2的结果是E1位右移E2位位置。如果E1 无符号类型，或者E1有符号类型且值为非负值， 结果值为E1 /商的积分部分 2 e2。如果E1具有符号类型和负值，则结果值为 是由实现定义的。

就CPU而言，位移运算比除法运算快。 然而，编译器知道这一点，并将适当地优化到它可以的程度， 因此，您可以以最有意义的方式编写代码，并且知道您的代码是有意义的 有效地运行。但是请记住，由于前面指出的原因，在某些情况下，无符号整型可以比整型更好地优化。 如果你不需要符号算术，那么不要包含符号位。

X/Y是正确的…和" >> "移位运算符..如果我们想要二除一个整数，我们可以使用(/)被除数运算符。移位运算符用于移位位。

x = x / 2; x / = 2;我们可以这样用…

这个问题的答案取决于你工作的环境。

If you're working on an 8-bit microcontroller or anything without hardware support for multiplication, bit shifting is expected and commonplace, and while the compiler will almost certainly turn x /= 2 into x >>= 1, the presence of a division symbol will raise more eyebrows in that environment than using a shift to effect a division. If you're working in a performance-critical environment or section of code, or your code could be compiled with compiler optimization off, x >>= 1 with a comment explaining its reasoning is probably best just for clarity of purpose. If you're not under one of the above conditions, make your code more readable by simply using x /= 2. Better to save the next programmer who happens to look at your code the 10 second double-take on your shift operation than to needlessly prove you knew the shift was more efficient sans compiler optimization.

所有这些假设都是无符号整数。简单的移位可能不是你想要的符号。此外，DanielH提出了一个关于在ActionScript等特定语言中使用x *= 0.5的好观点。

x / 2更清晰，x >> 1快不了多少(根据一个微基准测试，对于Java JVM快30%左右)。正如其他人所注意到的，对于负数，舍入略有不同，所以当您想处理负数时必须考虑这一点。一些编译器可能会自动将x / 2转换为x >> 1，如果他们知道这个数字不可能是负数(即使我无法验证这一点)。

即使x / 2可能不使用(慢)除法CPU指令，因为一些捷径是可能的，但它仍然比x >> 1慢。

(This is a C / C++ question, other programming languages have more operators. For Java there is also the unsigned right shift, x >>> 1, which is again different. It allows to correctly calculate the mean (average) value of two values, so that (a + b) >>> 1 will return the mean value even for very large values of a and b. This is required for example for binary search if the array indices can get very large. There was a bug in many versions of binary search, because they used (a + b) / 2 to calculate the average. This doesn't work correctly. The correct solution is to use (a + b) >>> 1 instead.)