C++编译器宏判断系统位数

在C++开发中，判断当前系统位数是常见需求，尤其在编写跨平台代码时，开发者需要明确编译出的程序运行在32位还是64位环境。最直接的方法是通过编译器宏进行判断，但不同工具链（如Windows上的MinGW和MSVC）存在差异，容易出错。

最可靠的做法是直接检查__LP64__和_WIN64这两个宏。它们在预处理阶段就已确定，不受运行时环境影响。GCC/Clang在LP64系统（如Linux/macOS）下定义__LP64__；MSVC在64位Windows下定义_WIN64。两者不重叠，覆盖主流平台，但MinGW等工具链需额外兜底——使用sizeof(void*)==8作为编译期回退。

使用 __LP64__ 和 _WIN64 判断64位系统最可靠

直接查询宏定义比依赖sizeof(void*)更早、更确定——编译器在预处理阶段就确定了这些宏，后续不会受运行时环境影响。GCC/Clang在LP64模型（如Linux x86_64、macOS ARM64/x86_64）下定义__LP64__；MSVC在64位Windows下定义_WIN64。两者不重叠，虽未覆盖所有平台，但主流场景已足够。

• __LP64__：Linux x86_64、macOS ARM64/x86_64均有定义，但Windows上的MinGW-w64默认不定义（除非显式添加-m64并启用LP64）。
• _WIN64：仅MSVC及其兼容工具链（如clang-cl）会定义，MinGW不识别此宏。
• 避免使用__x86_64__或__aarch64__替代——它们判断的是CPU架构，与“系统位数”不同。例如，ARM32上运行64位内核时，用户态仍可能是32位。

Windows下必须区分MSVC和MinGW工具链

同一Windows系统，使用MSVC编译时可通过_WIN64稳定判断，但切换到MinGW则失效。MinGW默认采用ILP32模型，即便目标架构为x86_64，也只定义__x86_64__，不定义_WIN64。此时需借助sizeof(void*) == 8兜底，但必须确保其出现在编译期常量上下文（如static_assert或模板参数）。

• MSVC：#ifdef _WIN64 → 表示64位Windows用户态。
• MinGW：#ifdef __x86_64__仅说明目标架构为x86_64，还需配合__MINGW64_VERSION_MAJOR（如有）或直接检测sizeof(void*)。
• 混用时最容易遗漏MinGW64的情况，导致在64位Windows下被误判为32位，且无警告。

sizeof(void*) 是最通用的兜底方案，但有编译期限制

当宏不可靠或跨平台抽象层需要统一逻辑时，sizeof(void*)是最终依据。但注意，它不能用于预处理器条件（#if sizeof(void*) == 8会报错），只能用于constexpr、static_assert或模板特化。

• 可行：static_assert(sizeof(void*) == 8, "64-bit expected");
• 不可行：#if sizeof(void*) == 8 —— 预处理器不识别sizeof。
• 模板中可写template struct is_64bit;，但不如宏直观。
• 某些嵌入式平台（如freestanding环境）可能连void*的定义都不稳定，此时宏仍是唯一选择。

避免依赖 INTPTR_MAX 或 SIZE_MAX

这些常量由头文件stdint.h或cstdint提供，属于编译结果而非编译器内置宏。若标准库头文件被裁剪或使用非标准实现（如某些RTOS），INTPTR_MAX可能未定义或值被硬编码为32位——它反映的是ABI，而非编译器对当前平台的判断。

• 使用#include 后才能用INTPTR_MAX，而宏判断无需任何头文件。
• INTPTR_MAX == INT64_MAX在大多数64位系统上成立，但某些32位系统（如DSP）也可能将其定义为INT64_MAX，仅为了支持大地址运算。
• 它与sizeof(void*)不一定同步：理论上可能存在sizeof(void*) == 4但INTPTR_MAX == 0x7fffffffffffffff（极少见，但标准允许）。

实际项目中，建议优先查宏，再fallback到sizeof(void*)，最后才考虑INTPTR_MAX。最容易忽略的是MinGW和MSVC在Windows上的行为差异——同一套代码，在Visual Studio中走_WIN64分支，用MinGW编译却无声无息地进入32位逻辑，且无警告。因此，多加留意才能避免问题。