关于Windows下C++开发的64位和32位通讯的问题

 现在64位的系统已经十分普及了。在MSRA实习的时候,几乎所有的Server都是64位的Windows Server,而我自己开发使用的机器还是普通的32位系统。在处理网络通讯的时候,经常需要把整数类型的数据转换成二进制流传输,那么就会遇到32位机器和64位机器之间通讯的情况。

  C++默认的int变量,都是根据具体编译环境来定,如果是32位下编译,就是4个字节宽度,如果是64位机器下就是8个字节宽度。那么在通讯的时候,我们需要强制同意按照一种整数宽度来读和写。Windows SDK里面已经提供了一个自定义的数据类型来实现统一宽度。在windef.h里面,INT, UINT,DWORD等通过typedef自定义的数据类型,无论在32还是64位下,都是统一的宽度。下面是我从MSDN上找到的比较官方的说明:

摘自:http://www.microsoft.com/china/MSDN/library/Windev/64bit/MW6TWPchapter5.mspx?mfr=true

5.3 编码问题

将 C/C++ 应用程序迁移到 64 位时,遇到的大部分编码问题可分为三类:指针转换、指针运算和对齐。在处理内联汇编程序,使用修改后的五个 API 调用之一,以及尝试跨 32/64 位边界通信时,可能会出现其他问题。

由于数据类型 Int 和 Long 的长度保持不变(仍为 32 位),因此需要修改的代码数量非常少。通常,所涉及的代码行数应该不到总代码基的 1%。这与 Unix 不同,其中 Long 要迁移到 64 位。

开发人员必须小心处理变量的对齐。未对齐对性能的影响非常严重。对于 x64,有一些性能影响,但是在 Itanium 系统上,问题更严重;异常将传播到应用程序层并会导致应用程序崩溃。

开发人员可以使用 –Wp64 编译器开关来要求编译器显示可能的移植性问题。这将使开发人员能够注意到绝大多数的移植问题。该标志在 32 位模式下同样可用。

5.3.1类型大小

从 32 位迁移到 64 位时,增长的主要类型是指针和派生数据类型,如句柄。在 Windows 64 位中,目前的指针和派生类型是 64 位 long 类型。大小增加的其他一些类型还有:WPARAM、LPARAM、LRESULT 和 SIZE_T。其中一个原因是,它们作为参数使用,并且某些函数将指针作为参数使用。

从“int”和“long”派生出的所有类型的大小仍然是 32 位,其中包括 DWORD、UINT 和 ULONG。小于 32 位的类型保留它们当前的大小。一个示例就是“short”数据类型,它仍然保留为 16 位的带符号整数。

正如前面提到的那样,Win32 API 保持不变。所进行的更改对应于五个替代函数;其中,四个由一个多态版本取代,一个用于平面滚动条:

GetClassLongPtr()

GetWindowLongPtr()

SetClassLongPtr()

SetWindowLongPtr()

这些函数的名称已经更改。此外,这些函数已经调整为使用多态数据类型(如 UINT_PTR),并使用所有更新的常量。

 

没有更多推荐了,返回首页