有关位运算的一则问题

[zengkun100]

今天编程时用到了这几个宏
#define MAKEWORD(a, b) ((WORD)(((BYTE)(a)) | ((WORD)((BYTE)(b))) << 8))
#define MAKELONG(a, b) ((LONG)(((WORD)(a)) | ((DWORD)((WORD)(b))) << 16))
#define LOWORD(l) ((WORD)(l))
#define HIWORD(l) ((WORD)(((DWORD)(l) >> 16) & 0xFFFF))
#define LOBYTE(w) ((BYTE)(w))
#define HIBYTE(w) ((BYTE)(((WORD)(w) >> 8) & 0xFF))

我想问一下那个HIBYTE(w)为什么要这样写。LOBYTE(w)直接拷贝w的低字节就行了，很好理解。如果要拷贝高字节的话，w右移8位不就可以了吗？为什么还要和0xFF与一下呢？一个BYTE类型的值和0xFF与好像是不变的吧！

[moany]

这个意思吧：
#define HIBYTE(w) ((BYTE)(((WORD)(w) >> 8) & 0xFF00))

[moany]

不对，前面是byte

[snowbirdfly]

恩~~
实际上是一样的~~~
但是这样写应该是更规范一些~~~

[zengkun100]

因为你即使不用写& 0xFF，结果是一样的。不知道是不是会有跟平台有关的考虑才这样写。

[pongba]

这代码还是平台相关的，sizeof(BYTE)又不一定是8

[Mr_Yang]

学习了。

[apassion1]

移位涉及到符号．按位运算操作比较容易取得你所想要的数．我个人认为Ｃ＋＋中，位运算是一个重点．

[megaboy]

HIBYTE(w)有没有&0xff是不一样的，完全两回事。在这里加上0xff的原因，是因为如果w是一个有符号数的话，当它是负数的时候，右移会造成在左边补1，这不是希望的结果，因此需要用0xff与一下，把高位的1去掉。那么为什么是0xff而不是0x00ff呢？其实在这里用0xff跟0x00ff是一样的，因为0xff是一个无符号16进制数，是一个字节，跟它进行与运算的数是一个两字节的word类型的数值，0xff会被自动提升为word，由于0xff是无符号数，其高位会被0填充，变成0x00ff，这样就能把高位的1去掉了。

[njSeeWhy]

同意楼上！主要是为了能正确处理有符号数。

[wohow]

megaboy(飞天御剑流之杀神一刀斩)的说法是错误的。有没有&0xFF都是一样的。因为(BYTE)强制转换保证即使是负数带来了高位1，也被去掉了，返回的是BYTE。

[playar0709]

这个和>>的操作有关，>>可是是算术右移，也可以是逻辑右移，带来的不同是本来右侧的doongxi
在右移以后，是被舍弃了，还是被移动到左侧了

vc使用的是前者，所以有没有，都一样

但有的编译器使用后者

---
: Chance is a gift for those who try

[megaboy]

嗯，漏看了前面还有一个BYTE，如果有这个BYTE，那就是相同的。

[crystal_heart]

很快就要用到64位系统了，这样做是为了将来在64位系统上，这些代码也能正确的进行编译。

[pongba]

playar:
C++对>>的行为是有明确定义的。如果目标值为unsigned值或 signed非负数 的话就相当于逻辑右移。如果为signed负数则结果由实现定义，一般来说即算术右移。
实际上标准中故意避免提到逻辑/算术位移，因为这是实现相关的。标准只说对于bit pattern会作怎样的改变。对value又会作怎样的改变。

wohow/megaboy:
关键在于WORD在定义上是否为有符号的，按理说WORD的定义应当为无符号的，因而将一个WORD右移的结果就相当于逻辑右移，没什么问题。之所以画蛇添足可能是为了保险;-)

[zengkun100]

今天看到了让我喷血的东西.
这几个宏定义出现在windef.h中.如果我没有记错的话.
但是我今天在VC6的windef.h和VC7的windef.h中看到的是:
VC6的写法
#define HIBYTE(w) ((BYTE)(((WORD)(w) >> 8) & 0xFF))
VC7的写法
#define HIBYTE(w) ((BYTE)(((WORD)(w) >> 8))
所以我觉得这个问题没有必要搞的太复杂了,连他们自己都有两套写法嘛!