根本原因是IEEE 754标准用有限二进制位表示无限循环小数,如0.1在二进制中为循环小数,赋值时即产生截断误差,导致0.1+0.2≠0.3。
float 和 double 会算错?根本原因不是 C++ 的 bug,而是 IEEE 754 浮点数标准用有限二进制位表示无限小数。比如 0.1 在二进制里是循环小数,必须截断,误差从赋值那一刻就存在。
典型现象:
double a = 0.1 + 0.2;这不是比较写错了,是
std::cout << (a == 0.3); // 输出 0(false)
a 实际存的是 0.30000000000000004 这类近似值。
std::fixed 和 std::setprecision?它们只控制输出格式,不改变存储精度。适合「显示需求明确」的场景,比如金额、UI 展示、日志打印。
常见误用:以为加了 setprecision(2) 就能当「四舍五入」用——它只是截断显示,内部值没变,后续计算仍带误差。
正确做法:
std::round(x * 100) / 100 做真正舍入(注意 round 对负数行为)std::fixed 控制输出位数
std::defaultfloat 和 std::fixed 在同一输出流中未重置boost::multiprecision 还是自定义定点数?取决于精度要求和性能容忍度:
boost::multiprecision::cpp_dec_float_50(50 位十进制精度),但运算比 double 慢 100 倍以上int64_t 运算long double —— 它在 x86-64 Linux 是 80 位扩展精度,但在 Windows MSVC 下常退化为 64 位,跨平台行为不可靠==?因为两个看似相等的计算结果,可能因中间步骤舍入差异而落在不同二进制表示上。
安全做法是引入 epsilon(容差)比较:
bool equal(double a, double b, double eps = 1e-9) {
re
turn std::abs(a - b) < eps;
}1e20)用 1e-9 会失效,应改用相对误差 std::abs(a-b)
NaN 时,== 和任何比较都返回 false,需先用 std::isnan() 判断实际项目里最常被忽略的一点:精度问题往往不出现在计算本身,而出现在输入解析和单位混用上。比如读取 JSON 中的 "price": 19.99,如果后端传的是字符串,前端用 std::stod 解析,就已经损失精度;更稳妥的是解析为整数分(1999),全程整数运算。