#pragma pack (n) 惹的祸

今天遇到了一个问题，使用数据流传输的数据在解析的时候数据错位。想了非常久，发现是#pragma pack (n)惹的祸。





首先。解析方使用了编译字节设置，可是在发送方没有使用，于是用相同的结构体解析数据时候，有两个字节被0占用了。后来统一使用。问题解决。





例如以下图的struct结构体：不使用#pragma pack (1)时候，在解析RemotPort后是没问题的，再解析RemotIp的时候，通过字节转换后。ip地址的前两位是0.0.X.X 原因是WORD不够4字节，编译器自己主动填了0占位。





这是给编译器用的參数设置，有关结构体字节对齐方式设置， #pragma pack是指定数据在内存中的对齐方式。

#pragma pack (n)             作用：C编译器将依照n个字节对齐。

#pragma pack ()               作用：取消自己定义字节对齐方式。





#pragma  pack (push,1)     作用：是指把原来对齐方式设置压栈，并设新的对齐方式设置为一个字节对齐

#pragma pack(pop)            作用：恢复对齐状态

因此可见，增加push和pop能够使对齐恢复到原来状态，而不是编译器默认，能够说后者更优，可是非常多时候两者区别不大

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvVGlubmFfemhhbmc=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">







如：

#pragma pack(push) //保存对齐状态

#pragma pack(4)//设定为4字节对齐

  相当于 #pragma  pack (push,4)  

 

#pragma  pack （1）           

作用：调整结构体的边界对齐，让其以一个字节对齐；<使结构体按1字节方式对齐>

可是假设调换一下结构体中DWORD和WORD的顺序。则结果又不同。例如以下：

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvVGlubmFfemhhbmc=/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">