请考虑
#include <iostream>
int main()
{
double a = 1.0 / 0;
double b = -1.0 / 0;
double c = 0.0 / 0;
std::cout << a << b << c; // to stop compilers from optimising out the code.
}
我一直认为a将会是+Inf，b将会是-Inf，c将会是NaN。但我也听说过有种传言，严格来讲，浮点数除以零的行为是未定义的，因此上面的代码不能被视为可移植的C++。（理论上这会摧毁我超过百万行的代码堆栈的完整性。哎呀！）
谁是正确的？
注意，我对实现定义感到满意，但我所说的是猫吃、恶魔打喷嚏般的未定义行为。
C++标准不强制使用IEEE 754标准，因为这主要取决于硬件架构。如果硬件/编译器正确实现了IEEE 754标准，则除法将提供预期的INF、-INF和NaN；否则，情况就不确定了。
未定义的含义是编译器实现决定的，其中有许多变量，例如硬件架构、代码生成效率、编译器开发人员的懒惰等。
C++标准规定，对0.0的除法是未定义行为。
C++检测IEEE754：
标准库包括一个模板，用于检测是否支持IEEE754：
static constexpr bool is_iec559;
#include <numeric>
bool isFloatIeee754 = std::numeric_limits<float>::is_iec559();
如果不支持IEEE754会发生什么？
这取决于情况，通常被0除会触发硬件异常并导致应用程序终止。
std::numeric_limits<T>::is_iec559()是一个实现定义的量，反映了符合IEC 559标准的声明，而不是实现正确支持IEEE 754的保证。这就是语言专家们的做法。 - Peter引用自 cppreference:
如果第二个操作数为零，则行为是未定义的，除非正在进行浮点除法并且该类型支持 IEEE 浮点算术（参见
std::numeric_limits::is_iec559），那么:
如果一个操作数是 NaN，则结果为 NaN
将非零数除以 ±0.0 会得到正确符号的无穷大并引发
FE_DIVBYZERO将 0.0 除以 0.0 会得到 NaN，并引发
FE_INVALID
这里讨论的是浮点除法，所以实际上是实现定义了是否将 double 除以零视为未定义行为。
如果 std::numeric_limits<double>::is_iec559 为 true，而且它通常是 "true 的"，那么行为是明确定义的，并产生预期的结果。
一个相当安全的选择是使用：
static_assert(std::numeric_limits<double>::is_iec559, "Please use IEEE754, you weirdo");
...在您的代码附近。
double的行为符合IEC559。它可能不会撒谎，否则它就违反了标准。IEC559独立于C++标准对double的行为施加限制；1.0/0.0的结果由IEC559定义。通过特性声明double is_iec559也是标准定义的。编译器可以选择不这样做，但这样做就是定义的。 - Yakk - Adam Nevraumontis_iec559 时，它会隐式地定义一次，因为如果声称支持 iec559，则编译器必须具有符合 iec559 的 double。然后该标准定义了 1.0/0.0 的行为。该标准将 iec559 标准作为 选项 引入范围，一旦被 "引入范围"，编译器必须符合两个标准。C++ 标准对 1.0/0.0 的行为没有 直接 限制；iec559 标准则有。只有一种方法可以同时符合 两个 标准。如果声称支持 is_iec559，则必须在 C++ 标准下支持 1.0/0.0。 - Yakk - Adam Nevraumont除数为零时，整数和浮点数的除法都是未定义行为 [expr.mul]p4:
二元运算符 / 返回商，二元运算符 % 返回第一表达式除以第二个表达式的余数。如果 / 或 % 的第二个操作数为零，则行为是未定义的。...
虽然实现可以选择支持Annex F，该附件具有浮点除零的明确定义的语义。
我们可以从这个clang bug报告中看到clang sanitizer将IEC 60559浮点除零视为未定义的，即使宏__STDC_IEC_559__被定义，它仍然被系统头文件定义，并且至少对于clang不支持Annex F，因此对于clang来说仍然是未定义的行为：
C标准的Annex F（IEC 60559 / IEEE 754支持）定义了浮点除以零，但是clang（3.3和3.4 Debian快照）将其视为未定义。这是不正确的：
支持附件F是可选的，我们不支持它。
#if STDC_IEC_559
这个宏是由系统头文件定义的，而不是我们定义的。这是你的系统头文件中的一个错误。（顺便说一句，据我所知，GCC也没有完全支持Annex F，所以这甚至不是Clang特有的bug。）
那个bug报告和其他两个bug报告UBSan：浮点数除以零不是未定义的 和 clang 应该支持 Annex F of ISO C (IEC 60559 / IEEE 754)表明gcc在浮点除以零方面遵循了Annex F。
虽然我同意C库无条件地定义STDC_IEC_559的做法是不对的，但这个问题是特定于clang的。GCC并没有完全支持Annex F，但至少它的意图是默认支持它，并且如果未改变舍入模式，则其除法是良定义的。现在不支持IEEE 754（至少基本特性，如处理除以零）被认为是不好的行为。
这得到了 GCC GCC浮点数学语义维基 的进一步支持，该维基表明 -fno-signaling-nans 是默认设置，与GCC优化选项文档相符合：
默认值是“-fno-signaling-nans”。
有趣的是，UBSan用于Clang，默认情况下在-fsanitize=undefined下包括float-divide-by-zero，而GCC则没有：
检测浮点数除以零。与其他类似的选项不同，-fsanitize = float-divide-by-zero未启用 -fsanitize = undefined，因为浮点数除以零可能是获得无穷大和NaN的合法方法。
#include <stdio.h>的工作方式，但没有描述确切的内容。声称符合ISO标准的编译器不能随意获取任何名为stdio.h的文件，并希望其中包含正确的内容。 - MSalters除以0是未定义行为。
来自C++标准（C++11）第5.6节：
二进制运算符
/返回商，二进制运算符%返回第一个表达式除以第二个表达式的余数。如果/或%的第二个运算符为零，则行为未定义。对于整数操作数，/运算符返回代数商，并舍去任何小数部分；如果商a/b在结果类型中可表示，则(a/b)*b + a%b等于a。
/运算符不区分整数和浮点数操作数。标准只声明了除以零是未定义的，而不考虑操作数。
％：乘法和除法的操作数应具有算术或未作用域枚举类型；％的操作数应具有整数或未作用域枚举类型。 - pipefloat更快地处理，同时提供更好的精度。 - supercat这也取决于浮点环境。
cppreference有详细信息： http://en.cppreference.com/w/cpp/numeric/fenv （没有示例）。
这应该在大多数桌面/服务器C++11和C99环境中可用。还有特定于平台的变化，早于所有这些标准化。
我希望启用异常会使代码运行更慢，因此出于这个原因，我所知道的大多数平台默认禁用异常。
std::cout << a << b << c;？ - WhiZTiM