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
它们确实能反映指针可表示的整数范围，但需要包含 intptr_t 足够存下任意对象指针，没强制其宽度等于 void*（尽管实际中总是相等）。更关键的是，INTPTR_MAX 是宏或常量，不能用于 #if 条件（除非是 C++20 的 consteval + 整数字面量，但兼容性差）。
立即学习“C++免费学习笔记（深入）”；
对比：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*) 只忠实地告诉你：此刻编译器认为指针多宽。
