C++23起标准库提供std::add_overflow安全检测整数加法溢出，定义于，支持有符号/无符号类型；C++11至C++17不支持，需C++23兼容编译器（如GCC 13+、Clang 16+）。
用 std::add_overflow 判断加法是否溢出（C++23 起）
标准库直到 C++23 才正式提供 std::add_overflow，它在
如果你实际环境是 C++23 或更高（如 GCC 13+、Clang 16+），可直接用：
int a = INT_MAX;
int b = 1;
int result;
if (std::add_overflow(a, b, &result)) {
// 溢出发生，result 值未定义
std::cout << "overflow!\n";
}-
std::add_overflow返回bool：true 表示溢出，false 表示成功，且*result被写入正确和值 - 支持所有整型（
char,short,int,long long,unsigned int等），但两个操作数与结果类型必须相同 - 对无符号类型，它检测的是数学意义上的“超出表示范围”，而非“回绕”——这符合大多数安全场景的预期
兼容 C++11 的手动溢出检测（推荐方案）
C++11 没有标准溢出检测机制，但可通过算术关系判断。核心思路是：对有符号加法 a + b，溢出只可能发生在同号相加时；对无符号，则检查结果是否“变小”。
以下为通用、无 UB、可内联的模板函数（适用于 C++11 起）：
立即学习“C++免费学习笔记（深入）”；
templatebool add_would_overflow(T a, T b) { static_assert(std::is_integral ::value, ""); if constexpr (std::is_signed ::value) { if (b > 0) return a > std::numeric_limits ::max() - b; else return a < std::numeric_limits ::min() - b; } else { return b > std::numeric_limits ::max() - a; } }
- 不执行实际加法，避免未定义行为（UB）；所有比较均在合法范围内进行
-
std::numeric_limits和::max() ::min()是 C++11 就支持的，无需额外头文件（只需 - 注意：不能写成
a + b 这类表达式——对有符号类型，a + b本身已是 UB，编译器可能优化掉整个判断
为什么 __builtin_add_overflow 不是跨平台解法
GCC 和 Clang 提供 __builtin_add_overflow(a, b, &result)，它在 C++11 下可用且高效，但它是编译器扩展，不是标准 C++。MSVC 不支持，Intel ICC 支持有限，交叉编译时易出问题。
- 返回
bool，语义与std::add_overflow一致，但名字带双下划线，属于保留标识符，不应在用户命名空间中复用 - 即使你只用 GCC/Clang，也建议将其封装在条件编译中，作为底层 fallback，而非直接暴露在业务逻辑里
- 例如：
#ifdef __has_builtin(__builtin_add_overflow)可用于运行时检测，但需注意宏定义时机
别忽略类型提升带来的隐式溢出风险
C++ 整型提升（integer promotion）会让小整型（如 int8_t）先转为 int 再运算，此时溢出检测对象其实是 int，而非原始类型。若你真要检查 int8_t x + int8_t y 是否在 int8_t 范围内溢出，必须显式 cast 回目标类型再判断。
- 错误示范：
int8_t a = 100, b = 100; bool ov = add_would_overflow(a, b);—— 此时T推导为int，检测的是int溢出，不是int8_t - 正确做法：
add_would_overflow，强制指定模板参数(a, b) - 更安全：统一用固定宽度类型（如
int32_t）并显式指定模板实参，避免依赖推导
实际项目中，最易被忽略的是「检测类型与运算类型不一致」和「有符号加法误用无符号逻辑」。只要确保模板参数显式、不依赖隐式提升、不执行未检查的中间加法，C++11 完全可以写出健壮的溢出判断逻辑。
