移植 - 共享内存 x32 和 x64 进程答案

【问题标题】：Porting - Shared Memory x32 & x64 processes移植 - 共享内存 x32 和 x64 进程
【发布时间】：2012-09-23 20:21:42
【问题描述】：

一个 32 位主机 Windows 应用程序设置共享内存（使用内存映射文件 / CreateFileMapping() API），然后其他 32 位客户端进程使用此共享内存相互通信。

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

为主机 x32 应用程序编写的原始代码几乎在所有地方都使用“size_t”，因为当我们从 x32 迁移到 x64 时，这从 4 字节到 8 字节不等，我正在寻找替换它。

我打算将“size_t”替换为“unsigned long long”，使其大小在 32 位和 64 位上相同。

你能建议我更好的选择吗？此外，“unsigned long long”的使用会对 x32 应用程序的性能产生影响.. 我想是的？

研究完成 - 发现非常有用的文章 - a) 从 32 位移植到 64 位的 20 个问题 (www.viva64.com) b) 无法使用编译器标志或任何钩子/骗子将 x64 平台上的“size_t”限制/更改为 4 个字节，因为它是 typedef

【问题讨论】：

这没有任何意义。 32 位进程仅限于将不超过 4 GB 的数据映射到其地址空间。适合 size_t 没有问题。
@HansPassant：如果我理解正确的话，他想对 32 位和 64 位版本使用相同的代码，并且它们必须是二进制兼容的，所以他不能使用任何类型两个平台上的定义不同。

【解决方案1】：

使用 64 位变量通常会降低 32 位应用程序的速度。

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

无论您选择什么类型，使用 typedef 给它一个有意义的名称是明智的，例如 shared_memory_address，并始终使用该名称。这样，您可以稍后根据需要更改基础类型。

【讨论】：