std::gcd 在 c++17 中才可用，别在旧标准里找它
如果你用 g++ 编译时报错 ‘gcd’ is not a member of ‘std’，大概率是编译器没开 C++17 或更高标准。GCC 和 Clang 默认不启用 C++17，必须显式指定：-std=c++17 或 -std=c++20。MSVC 2019 v16.10+ 默认支持，但老版本仍需确认。
常见错误现象：头文件写了 #include <numeric></numeric>，也用了 std::gcd(a, b)，但链接失败或编译报错——不是漏头文件，是标准版本卡住了。
- 检查方式：
std::gcd的声明在<numeric></numeric>中，但仅当__cpp_lib_gcd_lcm >= 201606L宏定义存在时才生效 - 替代方案：C++11 及以前只能手写欧几里得算法，比如
while (b) { auto t = b; b = a % b; a = t; } - 注意：
std::gcd(0, 0)返回0，符合数学定义，但部分手写实现会除零崩溃
std::gcd 要求两个参数同号，负数会出乎意料
std::gcd 对负数的处理是“取绝对值后计算”，但它的参数类型是整型模板（std::common_type_t<m n></m>），不自动转正。如果传入负数，结果仍是非负整数，但容易误判逻辑——比如你本想判断“是否互质”，却因符号问题漏掉边界情况。
使用场景：读取用户输入或解析文件得到的带符号整数，直接喂给 std::gcd 前没做清理。
立即学习“C++免费学习笔记（深入）”；
-
std::gcd(-12, 8)返回4，和std::gcd(12, 8)一样 -
std::gcd(-12, -8)同样返回4 - 但
std::gcd(0, -5)返回5，而有人可能预期是-5（实际不会，标准规定结果 ≥ 0） - 安全做法：显式取绝对值，如
std::gcd(std::abs(a), std::abs(b))，避免依赖隐式行为
std::lcm 的溢出风险比 gcd 高得多，尤其大数相乘
std::lcm(a, b) 内部等价于 std::abs(a) / std::gcd(a, b) * std::abs(b)，但乘法发生在除法之后——如果中间结果溢出，整个表达式就 UB（未定义行为）。而 std::gcd 只涉及取模，数值只减不增。
性能影响：std::lcm 多一次除法和一次乘法，但主要瓶颈不在运算本身，而在溢出检测缺失。
-
std::lcm(2000000000, 1999999999)在int上大概率溢出，即使最终结果能存进long long - 没有内置的溢出检查机制，也不会抛异常，结果是静默错误
- 若需安全 lcm，建议先转成
long long再调用：std::lcm(static_cast<long long>(a), static_cast<long long>(b))</long></long> - 或者手动检查：先算
g = std::gcd(a, b)，再判断abs(a)/g是否超过LLONG_MAX / abs(b)
windows MinGW 和某些 libc++ 版本对 std::lcm 支持不完整
MinGW-w64 的旧版 libstdc++（如 GCC 9.2 之前）实现了 std::gcd，但没实现 std::lcm；Clang + libc++ 12 之前也缺少 std::lcm。这时即使加了 -std=c++17，#include <numeric></numeric> 也不含 std::lcm 声明。
兼容性影响：跨平台项目在 linux（GCC 10+）能跑，在 Windows（MinGW GCC 8）直接编译不过。
- 检查方法：预编译宏
__cpp_lib_lcm应 ≥201606L，否则不保证存在 - 可加编译期断言：
static_assert(__cpp_lib_lcm >= 201606L, "std::lcm not available"); - 稳妥做法：自己封装一个 fallback lcm，用
std::gcd+ 类型提升 + 溢出防护 - 别依赖 ide 的头文件跳转——它可能显示声明，但链接时找不到符号
事情说清了就结束。最常被忽略的是：std::gcd 和 std::lcm 看似简单，但标准版本、符号处理、溢出路径、平台实现这四点，任一出错都会导致静默错误或编译失败，且难以定位。