17370845950

long long 的取值范围是 −9223372036854775808 到 9223372036854775807；C++ 中有符号溢出为未定义行为，运算不检查溢出，默认回绕，需用 __builtin_add_overflow 等内置函数手动检测。

long long 的取值范围到底是多少

在标准 C++ 中，long long 是至少 64 位的有符号整数类型，实际范围是 −2⁶³ 到 2⁶³ − 1，也就是：

-9223372036854775808 到 9223372036854775807

注意：这不是“大约 9e18”，而是精确到个位的边界。超出任一边界就会发生有定义但不可预测的溢出（对有符号类型，C++ 标准规定为未定义行为）。

为什么加法/乘法会悄无声息地溢出

C++ 默认不检查整数溢出，long long 运算结果一旦越界，就直接回绕（wrap around），且编译器通常不会报错或警告——除非你显式开启溢出检测。

• 常见错误现象：9223372036854775807 + 1 得到 -9223372036854775808，而不是报错或抛异常
• 使用场景：累加计数、幂运算、坐标计算、哈希组合等容易忽略边界的地方
• 编译器差异：GCC/Clang 支持 -fsanitize=signed-integer-overflow，启用后会在运行时报出 runtime error: signed integer overflow
• 性能影响：开启 sanitizer 会明显拖慢执行；生产环境一般关掉，靠测试和逻辑防御兜底

怎么安全地做 long long 的加减乘

没有内置的“安全算术”操作符，必须手动检查。别依赖 std::numeric_limits::max() 做减法预判——它容易写错条件。

• 加法检查：a > LLONG_MAX - b 表示 a + b 会溢出（假设 b ≥ 0）；需分别处理正负号
• 更稳妥的做法是用编译器内置函数：__builtin_add_overflow(a, b, &result)（GCC/Clang），返回 true 表示溢出
• 乘法尤其危险：LLONG_MAX / a 这类判断要小心除零、负数、边界值；__builtin_mul_overflow 更可靠
• 不要用 double 中转判断——double 只能精确表示 ≤ 2⁵³ 的整数，而 long long 能到 2⁶³，中间有大量“无法被 double 准确表达”的值

大整数真的只能换库吗

如果业务明确需要超过 long long 范围的整数（比如高精度金融计算、密码学、超大组合数），那确实该换库；但多数所谓“大整数需求”其实只是没控制好中间结果。

• 常见误判：以为 n * n * n 在 n = 1e6 时会爆——其实 1e18 还在 long long 范围内；但 n = 2e6 就超了
• 替代思路：提前模运算（如 (a * b) % MOD 改成 ((a % MOD) * (b % MOD)) % MOD）、分段计算、对数估算数量级
• 真要上大整数库：推荐 boost::multiprecision::int128（若支持）或 __int128（GCC 扩展，非标准）；跨平台项目慎用；完整大数请用 OpenSSL BN_* 或 libgmp

真正难的不是“怎么算更大”，而是“怎么确定当前逻辑是否真需要更大”——很多溢出 bug 其实源于算法设计时没想清楚数据规模。