必须包含<cmath>，std::ceil向上取整（≥x的最小整数），std::floor向下取整（≤x的最大整数），二者均返回double，对负数行为易误解：ceil(-2.3)得-2.0，floor(-2.3)得-3.0。
用 std::ceil 和 std::floor 前必须包含 <cmath>
这两个函数在 C++ 标准库中定义于 <cmath>，不是 <math.h>（C 风格头文件），也不在全局命名空间里。漏掉头文件或写错名字会直接编译失败，常见错误包括：‘ceil’ was not declared in this scope 或链接时报 undefined reference to ‘ceil’（尤其在某些旧编译器或未开 math 链接时）。
实操建议：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 始终写
#include <cmath>，而非<math.h> - 调用时用
std::ceil(x)或std::floor(x)，避免using namespace std;引发的隐式重载风险 - 传入类型推荐为
double；若传float，会先隐式转成double再计算，精度无损但可能掩盖本意；如需float版本，用std::ceilf(x)（C++11 起支持）
std::ceil 和 std::floor 对负数的行为要特别注意
向上取整（ceil）是“向正无穷取整”，向下取整（floor）是“向负无穷取整”。这不是四舍五入，也不是截断，所以负数结果容易反直觉：
例如：
立即学习“C++免费学习笔记（深入）”；
std::ceil(-2.3) // 结果是 -2.0（不是 -3） std::floor(-2.3) // 结果是 -3.0（不是 -2）
实操建议：
- 不要凭“上/下”字面理解方向，记口诀：“
ceil找 ≥ x 的最小整数，floor找 ≤ x 的最大整数” - 需要向零取整（即截断小数部分）时，别用这两个函数，改用
static_cast<long long>(x)（注意溢出）或std::trunc(x) - 对整数输入（如
std::ceil(5.0)），返回仍是浮点类型（double），不能直接赋给int变量而不显式转换
整数除法想“向上取整”？别套用 std::ceil，用整数技巧更安全
比如想算 “a 个物品分给 b 人，每人至少一个，最少需要几组”，即求 ⌈a/b⌉。如果 a、b 是正整数，直接写 std::ceil(static_cast<double>(a)/b) 看似可行，但有隐患：
- 当
a很大（接近LLONG_MAX）时，转double会丢失精度，导致结果错误 - 引入浮点运算，增加依赖和潜在异常（如
FE_INEXACT） - 性能略低，尤其在嵌入式或高频循环中
更推荐整数解法：
// a, b > 0 int ceil_div = (a + b - 1) / b;
原理：加 b-1 后再整除，能把所有非整除情况“推过”下一个整数边界。注意仅适用于正数；若含负数，需单独判断符号后处理。
编译器和平台差异：std::ceil 不一定生成 cvtsd2si 指令
在 x86-64 上，GCC/Clang 对 std::ceil 可能调用 glibc 的 ceil 函数（软实现），也可能内联为单条 roundsd 指令（取决于优化等级和目标架构）。但 MSVC 在 /fp:fast 下可能替换为近似指令，导致极少数边界值（如刚好在两个浮点数中间）行为不一致。
实操建议：
- 对数值精度要求严苛的场景（如金融、几何判定），避免依赖
std::ceil处理临界浮点值（如2.0000000000000004） - 可考虑用
std::nearbyint(x, FE_UPWARD)（C++11）配合浮点环境控制，但复杂度陡增 - 绝大多数应用里，
std::ceil/std::floor安全可靠，问题多出在误读语义或类型混用，而不是实现本身
实际用的时候，最常踩的坑不是函数不会调，而是把 ceil(-2.7) 想成 -3，或者对着整数除法硬塞浮点取整——那块逻辑往往才是真瓶颈。
