sqrt 和 pow：C++里那点“开方”和“次方”的小心思

写C++时遇到开平方、算幂次，很多人第一反应是头也不抬地敲下 sqrt(x) 或 pow(x, y)。用得顺手，但真要问一句：“它到底干了啥？我传个负数进去会怎样？为什么 pow(2, 0.5) 有时比 sqrt(2) 慢还不准？”——不少人就卡住了。

这不是考编译原理，而是日常调试里真实踩过的坑：比如物理模拟中能量衰减用了 pow(v, 2.0/3.0)，结果在某台Linux服务器上跑出 NaN；又比如嵌入式环境里 pow 链进了一大堆浮点库，而你其实只想要个整数平方根。

我们来把这两个函数从“黑盒”里拎出来，擦干净，看看里面装的是什么。

sqrt：专一，但也挑剔

sqrt 的本职工作非常明确：只算非负实数的主平方根。它不接受负数输入，连 -0.0 都能忍，但 -1.0 就直接返回 NaN（不是抛异常，是静默返回 NaN）。这点必须心里有数——它不报错，但结果已经失效。

更关键的是：sqrt 是数学函数，不是类型转换工具。
传 int 进去？自动转成 double 再算；传 float？升为 double 计算后再截回 float。如果你在性能敏感循环里反复对 int 调用 sqrt，不如先显式转成 double，避免隐式转换开销。

还有个容易被忽略的细节：sqrtf 和 sqrtl。
sqrtf(4.0f) 比 sqrt(4.0f) 快且精度匹配——前者用单精度算法，后者强制走双精度路径再降级。在图形渲染或音频处理这类 float 主导的场景里，选对后缀函数，省下的不只是几纳秒，更是确定性。

pow：灵活，但代价藏得深

pow(x, y) 看似万能：整数次方、小数次方、负指数、甚至复数（需 <complex>）……可它的实现逻辑远比 sqrt 复杂。主流 libm 库通常用 exp(y * log(x)) 实现，这意味着：

• x 必须 > 0，否则 log(x) 未定义 → 返回 NaN（哪怕 x == 0 && y > 0 这种合理情况，行为也依赖实现，不可靠）；
• x == 0 && y == 0 是未定义行为，C++ 标准没规定返回值，GCC 返回 1，Clang 可能返回 NaN；
• 整数小指数≠快：pow(x, 2) 理论上可优化为 x*x，但编译器不一定敢动——毕竟 x 可能是 NaN 或 Inf，而 x*x 会传播，pow 却可能按规范静默处理。

所以实际工程中：
✅ 对整数小幂（2、3、4），*直接手写 `xx、xxx**，清晰、零开销、无歧义； ✅ 对分数幂（如x^(1.0/3.0)），**优先考虑cbrt(x)（立方根）这类专用函数**，它们针对特定指数做了数值稳定优化； ❌ 别用pow(x, 0.5)替代sqrt(x)——多一次log+exp`，精度还略差，纯属自我加戏。

实战建议：什么时候该换思路？

有些问题，硬套 sqrt/pow 反而绕路：

• 判断是否为完全平方数？
  别 pow(round(sqrt(n)), 2) == n —— 浮点舍入会让 n=9999999999999999 这类大整数翻车。改用整数二分或 llround(sqrt(n)) 后验证平方，更稳。

• 计算 a^b mod m？
  pow(a,b) 先算巨大中间值再取模？内存爆、精度丢。必须手写快速幂（迭代版防栈溢出）+ 每步取模，这是算法题常识，也是密码学代码底线。

• 向量长度归一化？
  v.x = v.x / sqrt(v.x*v.x + v.y*v.y) —— 这里 sqrt 没问题，但若后续还要用模长倒数多次，*不如先算 inv_len = 1.0 / sqrt(...)，再 `v.x = inv_len`**。除法比开方贵得多，省一次就是赚。

最后一点实在话

C++ 标准库的数学函数，不是“越高级越该用”，而是“越贴近需求越该用”。
sqrt 是开方的终点，不是起点；pow 是通用接口，不是性能答案。
真正老手写代码，往往在头文件里默默加一行注释：
// sqrt(x): fast, strict; pow(x,y): flexible, fragile — choose by contract, not habit.

下次看到 pow(x, 0.5)，不妨停半秒：这真的是最直、最稳、最不容易在未来某天凌晨三点让你对着 core dump 发呆的写法吗？