“&0xFFFFFFFF”是什么意思？在这个 HIDWORD 宏中执行
我正在制作的程序需要 HIDWORD 宏，并在这里找到了这个宏： http://gnuwin32.sourceforge .net/compile.html
我困惑的是为什么它的末尾有一个 &0xFFFFFFFF ？
#define HIDWORD(l) ((DWORD)(((DWORDLONG)(l)>>32)&0xFFFFFFFF))
它如何以任何方式修改该宏的输出？
I needed the HIDWORD macro for a program I'm making and found this one here: http://gnuwin32.sourceforge.net/compile.html
What I'm confused about is why there is a &0xFFFFFFFF at the end of it?
#define HIDWORD(l) ((DWORD)(((DWORDLONG)(l)>>32)&0xFFFFFFFF))
How does that modify the output of this macro in any way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为它没有任何实际效果 -
(DWORD)强制转换表达式的最终操作无论如何都会将结果强制为 32 位。
(DWORDLONG)强制转换强制移位操作作用于无符号值，因此不会将“符号位”移入中间结果。然而，由于操作数可能是 64 位，因此在比位 31 更高的位置仍然可能存在非零位。 0xFFFFFFFF 操作会将这些位清零，但(DWORD)转换也会如此。但这也没有什么坏处。有人可能会说，它使宏的意图更加清晰（也许对你来说除外 - 只是开玩笑！）。
I don't think it has any real effect - the
(DWORD)cast thatthe final operation of the expression will force the result to 32 bits anyway.
The
(DWORDLONG)cast forces the shift operation to act on an unsigned value, so no 'sign bits' will be shifted into the intermediate result. However, since the operand could be 64-bits, there might still be non-zero bits at higher locations than bit 31. The& 0xFFFFFFFFoperation will zero out those bits, but so would the(DWORD)cast.But it doesn't hurt, either. One could argue that it makes the intent of the macro clearer (except to you, maybe - just kidding!).
它通过显式屏蔽高阶位来处理可能的符号扩展。您的编译器是否实际上确实对负数的右移进行符号扩展是实现定义的。编辑：符号扩展是指设置高位以在数字为数字时保留符号转移了。
例如：
如果我们假设它是一个8位二进制补码，则为-2。如果我们做一个简单的逻辑移位，我们会得到：
然而，这改变了数字的符号。许多编译器会进行算术移位，给出：
请注意，我们用 1 填充最高有效位（对于更复杂的示例，该位将不止 1）。
It's dealing with possible sign extension by explicitly masking out the high-order bits. Whether your compiler actually does sign extension for a right shift of a negative is implementation-defined.EDIT: Sign extension refers to setting the high-order bits to keep the sign when a number is shifted.
For example:
is -2, if we assume it's a 8-bit two's complement number. If we do a simple logical shift right, we get:
However, that changes the sign of the number. Many compilers will do a arithmetic shift, to give:
Note that we fill in the most significant bit (it would be more than one for a more complex example) with 1's.
假设这些是无符号类型，并且假设
DWORD是 32 位，DWORDLONG是 64 位，那么从技术上讲，它不会执行任何操作。也许这只是复制和粘贴签名类型的类似宏留下的代码？
或者我提到的假设之一可能不成立。
干杯&呵呵，
Assuming those are unsigned types, and assuming
DWORDis 32 bits andDWORDLONGis 64 bits, then technically it doesn't do anything.Perhaps it's just code left over from copy-and-paste of similar macro for signed types?
Or perhaps one the assumptions I noted doesn't hold.
Cheers & hth.,