移位，在32位int上移位32位 [英] shifting bits, shift 32 bits on 32 bit int
问题描述
注意到今天比特换档的方式有些奇怪。
据我所知，换档将以零为单位转换（签名后的内容
）一边）
然而，当我准确地移动一个值中的
位数时，我发现了一些奇怪的东西...即
uint32_t x = 5;
uint32_t y = x<< 32;
uint32_t z = x<< 32;
在上面的例子中，y和z都是5.这是为什么？
现在我明白做这样的班次了看起来很傻，但是在这段代码中，有时候产生的移位有效地证明了该数据类型中的位数是多少，并且期望结果为0。
我可以更改代码来处理这个特殊情况...我只是
想知道为什么会发生这种情况..
GGG写道：注意到今天位变换方式有些奇怪。
据我所知从来没有听说过，转移会以零的形式移动（签名后的内置）
然而，当我准确地移动一个值中的
位数时，我发现了一些奇怪的东西......即
uint32_t x = 5;
uint32_t y = x<< 32;
uint32_t z = x<< 32;
在上面的例子中，y和z都是5.这是为什么？
现在我明白做这样的转变似乎很傻，但在这段代码中
有时候产生的移位有效地证明是该数据类型中的位数，并且期望结果为0.
我可以更改代码来处理这个特殊情况...我只是想知道为什么会发生这种情况..
它将从右操作数确定的位数移动
将余数除以左操作数
中的总位数。取32，除以32，取余数，你得
得到0.这就是向左移动的位数。 IOW，none。没有。
如果你这样做
uint32_t x = 5;
uint32_t y = x< < 33;
你将得到y ==（uint32_t）10（最有可能，给出常见的含义
''uint32_t''）。
V
Victor Bazarov 2004-05-26：
GGG写道：注意到今天比特移动的方式有些奇怪。
据我所知，移位将以零（有符号的内置）移动
然而，当我准确地移动一个值中的
位数时，我发现了一些奇怪的东西...即
uint32_t x = 5;
uint32_t y = x<< 32;
uint32_t z = x<< 32;
在上面的例子中，y和z都是5.这是为什么？
现在我明白做这样的转变似乎很傻，但在这段代码中
有时候产生的移位有效地证明是该数据类型中的位数，并且期望结果为0.
我可以更改代码来处理这个特殊情况......我只是想知道为什么会发生这种情况..
它会改变从右操作数确定的位数
除以左操作数中的总位数。取32，除以32，取余数，你得到0.这就是向左移动的位数。 IOW，none。
如果你这样做
uint32_t x = 5;
uint32_t y = x<< 33;
你将得到y ==（uint32_t）10（最有可能是'uint32_t''的常见含义。）
确切地说，原因很简单：大多数硬件根据需要从移位值中获取尽可能多的位
，忽略更高值的位。
In uint32_t的情况，5位。换句话说，
uint32_t（x）<< y == uint32_t（x）<< （y& 31）
Walter Tross
" GGG" schrieb
uint32_t x = 5;
uint32_t y = x<< 32;
uint32_t z = x<< 32;
在上面的例子中，y和z都是5.这是为什么？
现在我明白做这样的转变似乎很傻，但在这段代码中<有时，结果移位有效地证明是该数据类型中的位数，并且期望结果为0.
你没想到的并不重要。仅当右操作数的值小于左操作数中的位数时，才定义移位的行为。因此，将32位值移动32或更多是未定义的，或者至少未在标准中指定，并且每个编译器都可以执行它认为最好的任何操作。
Heinz
Noticed something odd in the way bit shifting was working today.
As far as I have ever heard, shifting will shift in zeros(signed ints
aside)
However I foudn something odd when I am shifting exactly the number of
bits in a value... i.e.
uint32_t x = 5;
uint32_t y = x << 32;
uint32_t z = x << 32;
In the above example y and z are both still 5. Why is this?
Now I understand doing a shift like this seems silly, but in this code
sometimes the resulting shift validly turns out to be exactly the
number of bits in that data type, and expects the result to be 0.
I can change the code to handle this special case... I was just
wondering why this was happening..
GGG wrote:Noticed something odd in the way bit shifting was working today.
As far as I have ever heard, shifting will shift in zeros(signed ints
aside)
However I foudn something odd when I am shifting exactly the number of
bits in a value... i.e.
uint32_t x = 5;
uint32_t y = x << 32;
uint32_t z = x << 32;
In the above example y and z are both still 5. Why is this?
Now I understand doing a shift like this seems silly, but in this code
sometimes the resulting shift validly turns out to be exactly the
number of bits in that data type, and expects the result to be 0.
I can change the code to handle this special case... I was just
wondering why this was happening..
It shifts the number of bits determined from the right operand by
taking the remainder from dividing by the number of total bits in
the left operand. Take 32, divide by 32, take the remainder, you
get 0. That''s the number of bits shifted to the left. IOW, none.
If you do
uint32_t x = 5;
uint32_t y = x << 33;
you will have y == (uint32_t)10 (most likely, given common meaning
of ''uint32_t'').
V
Victor Bazarov 2004-05-26 :
GGG wrote:Noticed something odd in the way bit shifting was working today.
As far as I have ever heard, shifting will shift in zeros(signed ints
aside)
However I foudn something odd when I am shifting exactly the number of
bits in a value... i.e.
uint32_t x = 5;
uint32_t y = x << 32;
uint32_t z = x << 32;
In the above example y and z are both still 5. Why is this?
Now I understand doing a shift like this seems silly, but in this code
sometimes the resulting shift validly turns out to be exactly the
number of bits in that data type, and expects the result to be 0.
I can change the code to handle this special case... I was just
wondering why this was happening..
It shifts the number of bits determined from the right operand by
taking the remainder from dividing by the number of total bits in
the left operand. Take 32, divide by 32, take the remainder, you
get 0. That''s the number of bits shifted to the left. IOW, none.
If you do
uint32_t x = 5;
uint32_t y = x << 33;
you will have y == (uint32_t)10 (most likely, given common meaning
of ''uint32_t'').
Exactly, and the reason is simple: most hardware simply takes as many bits
from the shift value as needed, ignoring the higher valued bits.
In the case of uint32_t, 5 bits. In other words,
uint32_t(x) << y == uint32_t(x) << (y & 31)
Walter Tross
"GGG" schrieb
uint32_t x = 5;
uint32_t y = x << 32;
uint32_t z = x << 32;
In the above example y and z are both still 5. Why is this?
Now I understand doing a shift like this seems silly, but in this code
sometimes the resulting shift validly turns out to be exactly the
number of bits in that data type, and expects the result to be 0.
It doesn''t matter what you are expecting. The behaviour of shifts defined only if the value of the right operand is less than the number of bits in the left operand. So shifting a 32-bit value by 32 or more is undefined or at least not specified in the standard and each compiler may do whatever it thinks to be best.
Heinz
这篇关于移位，在32位int上移位32位的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
