移植 - 共享内存的X32＆x64的处理

一个32位主机的Windows应用程序的设置共享存储器（使用存储器映射的文件/的CreateFileMapping（）API），然后其他32位客户端进程使用该共享存储器互相通信。移植 - 共享内存的X32＆x64的处理

我打算将主机应用程序移植到64位平台，一旦准备就绪，我打算32位和64位客户机进程应该能够使用由主要64位主机应用程序设置的共享内存。

主机X32应用程序编写的原代码使用“的size_t”几乎无处不在，因为这4个字节到8个字节不同，因为我们从32倍到x64动，我找取代它。

我打算用“unsigned long long”替换“size_t”，以便它的大小在32位的位上是相同的64位。

你能否给我建议更好的替代方案？此外，使用“无符号long long”会对x32应用程序的性能产生影响。我猜是的？

研究完成 - 实测值非常有用的制品 - 一个）20在发出从移植32位到64位（www.viva64.com） b）否方式限制在x64 /改变 “的size_t”平台使用编译器标志或任何钩/骗子因为它的typedef

2012-09-23 dpb

它没有任何意义。一个32位的进程被限制为映射不超过4千兆字节到其地址空间。适合size_t没有问题。 –

@HansPassant：如果我理解正确，他希望对32位和64位版本使用相同的代码，并且它们必须是二进制兼容的，因此他不能使用任何不同的类型定义在两个平台上。 –

使用64比特变量的将通常的32位应用程序慢下来的4个字节。

不过：因为它通常是不可能在所有的流程相同的虚拟地址来定位的共享内存，你可能使用相对于共享内存块的开始地址;另外，由于您的应用程序将支持32位进程，因此共享内存块的大小可能会小于4GB。那么为什么不使用unsigned int？

无论您选择哪种类型，这将是明智的使用typedef给它一个有意义的名字，例如，shared_memory_address，并一直使用该名称。如果需要，您可以稍后更改基础类型。

2012-09-23 22:39:20

回答