带IEEE FP的整数到浮点转换 在支持IEEE-75 4FP算法的C++实现中，从积分到浮点类型的转换有哪些保证？< /P>

具体来说，将任何整数值转换为任何浮点类型是否总是定义良好的行为，可能导致值

+-inf

？或者是否存在导致未定义行为的情况

（请注意，我不是在问确切的转换，只是从语言标准的角度来看，执行转换始终是合法的）

在第7.4节（2008年）中说，它是定义明确的行为。但是它与IEEE-754有关，C/C++实现可以自由地尊重它，也可以不尊重它（参见zwol的答案）

当且仅当 目标格式的最大有限数为 在数量级上超过四舍五入浮点结果的指数 范围无限。默认结果由舍入方向属性和符号确定 中间结果如下：

（a） 将所有溢油输送至 ∞ 中间人的标志 结果

b） roundTowardZero将所有溢出带到格式的最大有限数，符号为 中间结果

（c） roundTowardNegative将正溢出携带到格式的最大有限数，并携带 负溢出到 −∞

d） roundTowardPositive将负溢出带到格式中最负的有限数，并且 将正溢出带到+ ∞

这4个点的所有情况都为从整数类型到浮点类型的转换提供了确定性结果

所有其他情况（无溢出）也通过IEEE-754标准给出的确定性结果进行了明确定义

IEC 60559（IEEE 754的当前后续标准）使整数到浮点的转换在所有情况下都得到了很好的定义，如中所述，但语言标准对该主题有最终决定权

在基本标准中，C++11第4.9节“浮点-整数转换”第2段规定了范围外整数到浮点转换的未定义行为。（报价是从文件，这是最接近的官方2011 C++标准，是公开的免费）。 整数类型或非范围枚举类型的PR值可以转换为浮点值 点类型。如果可能的话，结果是准确的。如果要转换的值在可以 无法表示，但无法准确表示值，这是一个由实现定义的选项 下一个较低或较高的可表示值。[注：如果无法计算整数值，则会导致精度损失 精确表示为浮动类型的值。-结束注释]如果转换的值在外部 可以表示的值的范围，行为未定义。如果源类型为bool，则值 false转换为零，true转换为一

我的。C标准用不同的词语表述了相同的内容（第6.3.1.4节第2段）

<> P> C++标准没有讨论C++实现IEC 60559一致浮点运算的意义。然而，C标准（最接近C11的在线可免费下载）确实在附件F中讨论了这个问题，C++实现者在C++留下一些未指定的东西时倾向于转向C来指导。附录F中没有明确讨论整数到浮点的转换，但F.1p1中有这样一句话：

自 负无穷大和正无穷大可以用IEC 60559格式表示，所有实数都是零 在可表示值的范围内

把这句话和6.3.1.4p2放在一起，我觉得C委员会的意思是，当整数的大小超出可表示的有限数范围时，整数到浮点的转换产生±Inf。这种解释符合IEC 60559规定的转换行为，因此我们可以合理地相信，这就是声称符合附录F的C实现所能做的

<>但是，将C标准的任何解释应用到C++是有风险的；在很长一段时间内，C++一直没有被定义为C的超集。

---

如果C++的实现预先定义了宏>代码＞STYCSTCIECIE599X<和/或文档以某种方式符合IEC 60559，并且不使用“以速度的名义编写浮点数学”的编译模式（默认情况下可能是默认的），则可以依赖于超出范围的转换以产生±If。是UB.< /P>我不知道你在引用什么，但它不是C++标准，它是IEEE-75标准。对不起。我将撤消投票，但不幸的是C++标准在这里有优先权，它使范围转换不被定义，正如我在回答中所讨论的。我不知道那一点。因此，编译常量（由编译器计算）可能是不确定的，但如果目标体系结构符合IEEE-754，则生成的代码可能是确定的。不，这不是一个安全的假设。运行时转换生成的代码可能会在不同范围的情况下崩溃或产生垃圾，或者编译器可能推断出控制路径导致超出范围转换，并从理论上删除它不会发生的C++。“它们可以代表一系列值”。这使得很难以令人满意的方式回答此类问题。@KerrekSB是的，但它也有符合iec559（例如，