C++ 32 位与 64 位浮动限制

鉴于代码段如下，我只想知道

• 为什么64位的long double的最大值比32位的要小？
• 为什么 64 位版本无法扩展与 32 位版本一样多的位数来填充“40”精度输出？
• LDBL_MIN 和 LDBL_MAX 的值似乎相等，这是一个错误吗？

我查看了我的机器中的 float.h 文件，但找不到这些宏常量的显式定义。

测试代码（平台=Win7-64位）

#include <cfloat>
#include <iomanip>
cout<<"FLT_MAX   ="<< setprecision(40) << FLT_MAX  << endl;
cout<<"DBL_MAX   ="<< setprecision(40) << DBL_MAX  << endl;
cout<<"LDBL_MAX  ="<< setprecision(40) << LDBL_MAX << endl;
cout<<"FLT_MIN   ="<< setprecision(40) << FLT_MIN  << endl;
cout<<"DBL_MIN   ="<< setprecision(40) << DBL_MIN  << endl;
cout<<"LDBL_MIN  ="<< setprecision(40) << LDBL_MIN << endl;

32 位结果 (MinGW-20120426)

FLT_MAX  =340282346638528859811704183484516925440
DBL_MAX  =1.797693134862315708145274237317043567981e+308
LDBL_MAX =1.189731495357231765021263853030970205169e+4932
FLT_MIN  =1.175494350822287507968736537222245677819e-038
DBL_MIN  =2.225073858507201383090232717332404064219e-308
LDBL_MIN =3.362103143112093506262677817321752602598e-4932

64 位结果 (MinGW64-TDM 4.6)

FLT_MAX  =340282346638528860000000000000000000000
DBL_MAX  =1.7976931348623157e+308
LDBL_MAX =1.132619801677474e-317
FLT_MIN  =1.1754943508222875e-038
DBL_MIN  =2.2250738585072014e-308
LDBL_MIN =1.132619801677474e-317

Thanks.

[编辑]：使用最新的 MinGW64-TGM 4.7.1，LDBL_MAX、LDBL_MIN 的“错误”似乎已被删除。

LDBL_MAX =1.132619801677474e-317听起来像是某个地方的错误。标准要求每个值都可以表示为double也可以表示为long double，所以不允许LDBL_MAX < DBL_MAX。鉴于您尚未显示真正的测试代码，我个人会在指责编译器之前检查一下。

如果确实存在（非错误）差异long double两者之间，那么这种差异的基础将是您的 32 位编译器使用较旧的 x87 浮点运算，该运算具有 80 位精度，因此允许 80 位long double.

您的 64 位编译器在 x64 中使用较新的 64 位浮点运算。没有 80 位精度，也不需要切换到 x87 指令来实现更大的精度long double.

可能还有比这更复杂的事情。例如，并非所有 x86 编译器都必须具有 80 位long double。他们如何做出这个决定取决于多种因素，可能包括 SSE2 具有 64 位浮点运算这一事实。但可能性是long double大小与double，或者说它更大。

为什么 64 位版本无法扩展与 32 位版本一样多的位数 填充“40”精度输出？

双精度数只有大约 15 位小数位的精度。超出此范围的数字有时会提供信息，但通常会产生误导。

我不记得标准说了什么setprecision，但假设允许实现在停止生成数字的地方画一条线，则 a 的精度double是绘制它的合理位置。至于为什么一个实现决定实际执行它而另一个却没有——我不知道。由于它们是不同的发行版，因此它们可能使用完全不同的标准库。

同样的“虚假精度”就是你看到的原因340282346638528859811704183484516925440在一种情况下对于 FLT_MAX，但是340282346638528860000000000000000000000在另一个。一个编译器（或者更确切地说，一个库实现）不厌其烦地计算大量数字。另一个则早早放弃并圆了。