17370845950

sizeof(void*) 是最直接可靠的编译时判断指针宽度的方式，其值为4或8可明确区分32位或64位目标环境，不依赖运行时API、跨平台兼容，且支持C++98起的预处理器条件编译。

用 sizeof(void*) 判断指针大小就是判断系统位数

在 C++ 中，sizeof(void*) 是最直接、最可靠的编译时方式来区分 32 位和 64 位环境。它不依赖运行时 API，也不受目标平台 ABI 混淆（比如 Windows 上的 LLP64 和 Linux 的 LP64 都保证 void* 在 64 位下为 8 字节），所有主流编译器（MSVC、GCC、Clang）都严格遵守这一规则。

注意：这不是“检测当前操作系统”，而是“检测当前编译目标的指针宽度”——也就是你代码跑在哪种 ABI 下。交叉编译时，它反映的是 -m32 或 -m64 的设定，不是宿主机系统位数。

常见误用：
– 错把 sizeof(int) 当依据（x86_64 下仍是 4）
– 试图用 GetNativeSystemInfo() 等 Windows API 做跨平台判断（不可移植）

编译期分支：用 #if 配合 sizeof(void*)

必须配合预处理器做编译期分叉，不能写成运行时 if——因为 sizeof 是常量表达式，但直接写 if (sizeof(void*) == 8) 会导致两边代码都被编译，可能触发未定义行为或链接失败（比如引用只在 64 位才声明的符号）。

• ✅ 正确写法（编译期裁剪）：

  #if sizeof(void*) == 8
      // 64-bit only code
      uint64_t addr = reinterpret_cast(ptr);
  #else
      // 32-bit only code
      uint32_t addr = reinterpret_cast(ptr);
  #endif

• ❌ 错误写法：if (sizeof(void*) == 8) { ... } —— 运行时无意义，且无法规避类型不匹配警告
• ⚠️ 注意：某些嵌入式平台（如 AVR）sizeof(void*) 可能是 2 或 3，但这类平台极少用“位数”描述，通常不纳入“32/64 位系统”讨论范畴

为什么不用 INTPTR_MAX 或 UINTPTR_MAX

它们确实能反映指针可表示的整数范围，但需要包含 ，且值依赖于具体实现：C++ 标准只要求 intptr_t 足够存下任意对象指针，没强制其宽度等于 void*（尽管实际中总是相等）。更关键的是，INTPTR_MAX 是宏或常量，不能用于 #if 条件（除非是 C++20 的 consteval + 整数字面量，但兼容性差）。

对比：sizeof(void*) 是字面常量表达式，C++98 起就支持用于预处理条件，零依赖、零头文件、零宏定义风险。

典型陷阱：
– #if INTPTR_MAX == INT64_MAX 在 MSVC x64 下会失败，因为 INTPTR_MAX 展开为 0x7fff...fff（十六进制字面量），而预处理器不解析十六进制运算
– #include 后再 #if 仍不可靠，因头文件内容可能被宏污染

Windows 上特别要注意的 MSVC 兼容性

MSVC 对 sizeof(void*) 的处理完全标准，但容易踩的坑来自项目配置和平台工具集：

• 确保项目属性 → “常规” → “平台工具集” 与目标一致（例如 v143 工具集默认支持 x64；旧工具集可能禁用 64 位）
• 检查“配置管理器”里的“活动解决方案平台”是否设为 x64 或 Win32，而非 Any CPU（VS 里没有这个选项，选错会导致 sizeof(void*) 固定为 4）
• 命令行编译时，不要混用 vcvarsall.bat amd64 和 cl /arch:IA32 —— 后者会覆盖前者，导致 sizeof(void*) 仍为 4
• 调试时若看到 sizeof(void*) == 4 但期望是 64 位，先查 _M_X64 或 _M_AMD64 宏是否定义（这是 MSVC 提供的辅助宏，但不如 sizeof 通用）

真正麻烦的从来不是怎么写判断，而是让整个构建链（CMake、IDE、CI

脚本）统一指向同一个目标架构——sizeof(void*) 只忠实地告诉你：此刻编译器认为指针多宽。