为什么 fpclassify() 宏定义在 math.h 而不是 float.h？答案

【问题标题】：Why fpclassify() macro is defined in math.h and not in float.h?为什么 fpclassify() 宏定义在 math.h 而不是 float.h？
【发布时间】：2021-04-26 22:00:54
【问题描述】：

N2479 C17..C2x 工作草案 — 2020 年 2 月 5 日 ISO/IEC 9899:202x (E)：

7.12.3.1 The fpclassify macro:
Synopsis
#include <math.h>
int fpclassify(real-floating x);

为什么fpclassify()宏定义在math.h而不是float.h？

动机/理由/论证是什么？

【问题讨论】：

这个宏是在 C99 中添加的，C99 的基本原理没有提到为什么它（或“分类宏”组）被专门放在 math.h 中。
嗯 ... "返回： fpclassify 宏返回与其参数值相匹配的数字分类宏的值。"而*number分类宏”定义在<math.h>...现在问“为什么FP_INFINITE等，定义在<math.h>？”
因为他们喜欢它

标签： c floating-point macros

【解决方案1】：

虽然我不能代表 C 标准委员会成员发言，或者为什么他们选择一件事而不是另一件事，但我可以说的是 @987654321 @ header 包含（大部分）编译时常量的定义，这些定义定义了各种浮点数据类型的任何特定于架构的属性（特征）。

但是，<math.h> 标头提供了包含 C 标准库的数学函数的函数的原型，以及这些函数使用和/或返回的相关常量（例如 FP_INFINITE）。这些函数返回运行时值。

现在，尽管标准将fpclassify 定义为宏，但任何实现都只能根据代码（很可能涉及函数调用）来定义它——必须——在运行时进行评估时间。（否则它将如何处理作为参数给出的变量？）

【讨论】：

任何实现都只能在代码方面定义（很可能涉及函数调用） FWIW，Linux 和 Solaris 在使用 @987654326 时在链接时需要 -lm @。我还怀疑委员会强烈考虑了当时的实施。如果 Sun、HP 和 GNU/FSF 的 C 环境已经在 math.h 中实现了 fpclassify()，委员会就不会改变这一点。我似乎记得 ANSI C/C89 背后的驱动力是现有 C 的编纂和标准化，而不是新功能的创建。这可能会延续到 C99。

【解决方案2】：

根据 C 2018 5.2.4.2.2，float.h 提供了“浮动类型的特征”。因此，它定义了描述类型的宏，例如描述它们的精度和范围、使用什么基数等等。在设计 C 实现时，所有这些都是固定的。

fpclassify 是对值的操作。结果是根据参数计算得出的，因此它是数值的数学函数，而不是浮点类型的特征。

另请注意，<float.h> 和 <limits.h> 与其他标头分开指定。这两个在 C 标准的“环境限制”部分中，其中涵盖了 C 实现的特征。（它们也在“库”部分中作为存根列出，参考“环境限制”部分。）

【讨论】：

@njuffa：不，它没有改变；我忽略了它们也列在第 7 条中（尽管就像引用 5.2.4.2 的存根一样）。它们只是用值定义宏，而不是任何函数或对象，因此它们不符合 7.1.2 1 中标准头文件的描述：“……头文件声明了一组相关函数，以及任何必要的类型和所需的附加宏方便他们使用……”但我会删除或改写。谢谢。