c语言吧 关注：799,020贴子：4,353,384
XeO2 一切都要从NAN这个看起来平平无奇的宏说起。前几天lz正在捣鼓C++的numeric_limits，它有一个成员函数quiet_NaN，GCC和Clang的实现是这样的：
我依稀记得宏NAN好像也是这么实现的，为了验证这个已然模糊不清的印象，lz迫不及待地打开了<float.h>。
果然是这样，看来我的记性还不算差。
其实lz曾经不止一次地翻看过<float.h>，不过当时大抵是走马观花罢了，然而这一次，我的目光被这个熟悉而又陌生的宏定义吸引住了。
再仔细看一眼？
欸？不对呀，这怎么是个函数调用啊？C标准明明要求NAN展开成一个常量表达式，函数调用怎么可能是常量表达式，C语言有返回常量表达式的函数吗？
难不成是GCC对<float.h>施了什么魔法？可是从头认真看了一遍<float.h>之后，也没发现这个标准头有任何特殊的地方。
既然如此，就只好亲自编写代码为__builtin_nanf验明正身了，是真常量还是伪君子，一试便知！
编译，运行！
竟然通过了？！看来确实不关<float.h>的事，__builtin_nanf("")就是可以在任何位置表现出常量表达式的性质。
等等，先不要急着下结论，说不定GCC在编译过程中做了什么手脚，先看看预处理器怎么说，gcc -E走起。
__builtin_nanf纹丝不动，说明它并非是一个用来混淆视线的宏，现在可以肯定GCC不是在预处理阶段，而是在编译阶段把__builtin_nanf("")给换掉了，再看看IDA怎么说。
__builtin_nanf不见了，GCC把几个寄存器倒来倒去，其实就是把float类型的NAN转换成了double类型的NAN，果然是这样。
折腾了一通，最后发现__builtin_nanf("")被编译器替换成了一个立即数，这显然不是我们想要的，既然GCC手册上说__builtin_nanf是一个函数，那么我们一定要让这个函数显露出它的庐山真面目。
首先，函数是可以取地址的；其次，能接受字符串字面量参数的函数，也必定能接受字符数组名。思路已经有了，测试代码立刻安排上。
编译，运行，printf不出意料地输出了一个正常的地址，__builtin_nanf也笑纳了我们输入的字符串，并且依旧返回了一个NAN，最终程序也正常退出了。
这里需要说明一点，如果参数是字符数组名，__builtin_nanf的返回值就不是常量表达式了。
我依稀记得宏NAN好像也是这么实现的，为了验证这个已然模糊不清的印象，lz迫不及待地打开了<float.h>。
果然是这样，看来我的记性还不算差。
其实lz曾经不止一次地翻看过<float.h>，不过当时大抵是走马观花罢了，然而这一次，我的目光被这个熟悉而又陌生的宏定义吸引住了。
再仔细看一眼？
欸？不对呀，这怎么是个函数调用啊？C标准明明要求NAN展开成一个常量表达式，函数调用怎么可能是常量表达式，C语言有返回常量表达式的函数吗？
难不成是GCC对<float.h>施了什么魔法？可是从头认真看了一遍<float.h>之后，也没发现这个标准头有任何特殊的地方。
既然如此，就只好亲自编写代码为__builtin_nanf验明正身了，是真常量还是伪君子，一试便知！
编译，运行！
竟然通过了？！看来确实不关<float.h>的事，__builtin_nanf("")就是可以在任何位置表现出常量表达式的性质。
等等，先不要急着下结论，说不定GCC在编译过程中做了什么手脚，先看看预处理器怎么说，gcc -E走起。
__builtin_nanf纹丝不动，说明它并非是一个用来混淆视线的宏，现在可以肯定GCC不是在预处理阶段，而是在编译阶段把__builtin_nanf("")给换掉了，再看看IDA怎么说。
__builtin_nanf不见了，GCC把几个寄存器倒来倒去，其实就是把float类型的NAN转换成了double类型的NAN，果然是这样。
折腾了一通，最后发现__builtin_nanf("")被编译器替换成了一个立即数，这显然不是我们想要的，既然GCC手册上说__builtin_nanf是一个函数，那么我们一定要让这个函数显露出它的庐山真面目。
首先，函数是可以取地址的；其次，能接受字符串字面量参数的函数，也必定能接受字符数组名。思路已经有了，测试代码立刻安排上。
编译，运行，printf不出意料地输出了一个正常的地址，__builtin_nanf也笑纳了我们输入的字符串，并且依旧返回了一个NAN，最终程序也正常退出了。
这里需要说明一点，如果参数是字符数组名，__builtin_nanf的返回值就不是常量表达式了。
用IDA反汇编刚才的程序，汇编代码如下：
神秘的__builtin_nanf终于露出了它的真面目，点进去看一下这个函数究竟有什么东西。
哈哈哈哈，GCC是真的懒，直接返回一个硬编码的常数就完事。
__builtin_nanf的汇编代码实在是让人大跌眼镜，丝毫没有值得激动的地方。不过__builtin_nanf的存在却给我们展示了一种可能性，既然有一个__builtin_函数可以返回常量表达式，那么其他__builtin_函数是不是也可以呢？
__builtin_ctz可以计数一个二进制整数尾部连续的零的数量，显然，如果这个函数的参数是整数常量，那么它的返回值也应该是整数常量表达式，事不宜迟，测试代码安排上：
激动人心的时刻到来了，编译，运行，结果究竟如何，让我们拭目以待。
OHHHHHHH!!成功了！__builtin_ctz果然不负众望。
不只是__builtin_ctz，很多其他__builtin_函数同样也是可以的。这应该是一个非常令人振奋的结果，虽然诸如__builtin_ctz这样的位操作函数实现起来很容易，但是要想让结果是整数常量表达式就很麻烦了，现在有了__builtin_函数的助力，即便是需要常量表达式的场景也不再费事了。
神秘的__builtin_nanf终于露出了它的真面目，点进去看一下这个函数究竟有什么东西。
哈哈哈哈，GCC是真的懒，直接返回一个硬编码的常数就完事。
__builtin_nanf的汇编代码实在是让人大跌眼镜，丝毫没有值得激动的地方。不过__builtin_nanf的存在却给我们展示了一种可能性，既然有一个__builtin_函数可以返回常量表达式，那么其他__builtin_函数是不是也可以呢？
__builtin_ctz可以计数一个二进制整数尾部连续的零的数量，显然，如果这个函数的参数是整数常量，那么它的返回值也应该是整数常量表达式，事不宜迟，测试代码安排上：
激动人心的时刻到来了，编译，运行，结果究竟如何，让我们拭目以待。
OHHHHHHH!!成功了！__builtin_ctz果然不负众望。
不只是__builtin_ctz，很多其他__builtin_函数同样也是可以的。这应该是一个非常令人振奋的结果，虽然诸如__builtin_ctz这样的位操作函数实现起来很容易，但是要想让结果是整数常量表达式就很麻烦了，现在有了__builtin_函数的助力，即便是需要常量表达式的场景也不再费事了。
__builtin_函数返回常量表达式不得不说是惊喜，但却并不那么意外，毕竟它们本来就是编译器内置的函数，作些优化也是情理之中，这样编译器就可以拿它们来满足一些特殊的需求。不过现在这些都不重要了，因为接下来，就是见证奇迹的时刻！
让我们先来回头看看前面那个__builtin_nanf程序的汇编代码：
等等，好像哪里有点不对？我们调用的是__builtin_nanf函数，可是call指令后面出现的，却分明是另一个名字：nanf。
nanf是什么？它是<math.h>提供的标准库函数。等一下，你刚才说什么？“标-准-库-函-数”？难道说？
万一这个代码也能编译通过……此时此刻我已经紧张得心怦怦直跳，屏幕上的光标随着我的手不住地颤抖。
WHAT THE F__K????
冷静一下，刚才发生了什么？前面我们从__builtin_nanf类比推理得到其他__builtin_函数也有可能返回常量表达式，现在nanf可以返回常量表达式这一事实同样向我们揭示了一种可能性，那就是<math.h>提供的其他库函数也具有返回常量表达式的能力！
先试一下pow：
真的可以！
再试一下log：
How amazing!!!!
考虑到常量表达式是可以传递的，不妨来整点花活：
实在是太有趣啦！
让我们先来回头看看前面那个__builtin_nanf程序的汇编代码：
等等，好像哪里有点不对？我们调用的是__builtin_nanf函数，可是call指令后面出现的，却分明是另一个名字：nanf。
nanf是什么？它是<math.h>提供的标准库函数。等一下，你刚才说什么？“标-准-库-函-数”？难道说？
万一这个代码也能编译通过……此时此刻我已经紧张得心怦怦直跳，屏幕上的光标随着我的手不住地颤抖。
WHAT THE F__K????
冷静一下，刚才发生了什么？前面我们从__builtin_nanf类比推理得到其他__builtin_函数也有可能返回常量表达式，现在nanf可以返回常量表达式这一事实同样向我们揭示了一种可能性，那就是<math.h>提供的其他库函数也具有返回常量表达式的能力！
先试一下pow：
真的可以！
再试一下log：
How amazing!!!!
考虑到常量表达式是可以传递的，不妨来整点花活：
实在是太有趣啦！
草酱
这时可能有人就要问了：“我知道常量表达式有很多好处，可是这和函数又有什么关系呢？既然返回常量表达式的函数的参数也必须是常量表达式，那我直接把函数调用的结果写在代码里面就好了，何必多此一举地再调用一个函数呢？”
这个问题问得好，回答也是简单明确的：因为有些常量确实是编译时常量，但你编写代码时却并不知道这个常量等于多少。
C++的模板可以轻而易举地提供无数个这样的例子：
a, c, m显然都是编译时常量，但是编写函数模板时你并不知道它们仨是多少。
C语言也可以做到类似的事情，但是要稍微麻烦一点：
除了这些刻意构造的例子，还有许多不能忽视的宏常量，它们往往随着平台的不同而变化，这些常量的存在都有力地证明了一点，即“编译时常量”不等于“写代码时就知道的量”。
还有一种情况，虽然不是非得用返回常量表达式的函数，但是这么做明显会让代码更简洁清晰。
举个例子，现在需要用一个静态数组存储ln1到ln10以备将来计算所用，常规做法是这样的：
定义一个数组->手动计算出ln1到ln10->把计算结果复制到数组的初始化器当中。
我没有贬低这种方法的意思，从某种程度上来说，这几乎是唯一正确的做法，但弊端也是显而易见的，首先这么写代码很累，其次如果不写注释的话，阅读这段代码的人恐怕会被一群魔法数字弄得一头雾水，如果用函数的话，感觉就完全不一样了：
static double ln[11]={nan(""), log(1), log(2), log(3), log(4), log(5), log(6), log(7), log(8), log(9), log(10)};
就算不写注释，也绝对不会有人看不懂。
这个问题问得好，回答也是简单明确的：因为有些常量确实是编译时常量，但你编写代码时却并不知道这个常量等于多少。
C++的模板可以轻而易举地提供无数个这样的例子：
a, c, m显然都是编译时常量，但是编写函数模板时你并不知道它们仨是多少。
C语言也可以做到类似的事情，但是要稍微麻烦一点：
除了这些刻意构造的例子，还有许多不能忽视的宏常量，它们往往随着平台的不同而变化，这些常量的存在都有力地证明了一点，即“编译时常量”不等于“写代码时就知道的量”。
还有一种情况，虽然不是非得用返回常量表达式的函数，但是这么做明显会让代码更简洁清晰。
举个例子，现在需要用一个静态数组存储ln1到ln10以备将来计算所用，常规做法是这样的：
定义一个数组->手动计算出ln1到ln10->把计算结果复制到数组的初始化器当中。
我没有贬低这种方法的意思，从某种程度上来说，这几乎是唯一正确的做法，但弊端也是显而易见的，首先这么写代码很累，其次如果不写注释的话，阅读这段代码的人恐怕会被一群魔法数字弄得一头雾水，如果用函数的话，感觉就完全不一样了：
static double ln[11]={nan(""), log(1), log(2), log(3), log(4), log(5), log(6), log(7), log(8), log(9), log(10)};
就算不写注释，也绝对不会有人看不懂。
说了这么半天，也该把6L卖的关子在这里交代清楚了。lz测试了GCC和Clang这两个编译器，根据函数返回类型的不同，把它们分为两类：返回整数/算术常量表达式的函数和返回指针常量表达式的函数。构建测试程序所用的批处理代码如下：
GCC和Clang都用-O0显式禁用优化，以保证测试中通过的函数在不开优化时也可以正常使用。
返回整数常量表达式或算术常量表达式的函数的测试代码如下：
所有函数都必须通过枚举常量（必须是整数常量表达式）和静态初始化器（必须是常量表达式）测试。
测试结果如下：
说实话，<complex.h>里面的复函数能出现在这里实在是大为出乎意料，因为这些函数真的很复杂，别说是返回常量表达式了，就算是用常规方法实现一个都殊为不易。
返回指针常量表达式的函数只能用于静态初始化器，它们的测试代码与上述大同小异，这类函数不需要通过枚举常量测试，只需要通过静态初始化器测试即可，结果如下：
以下标准头提供的库函数lz未进行测试，但从它们的功能来看大概率不行：
<fenv.h>, <setjmp.h>, <signal.h>, <stdatomic.h>
所有未列举于此的标准头和库函数，要么是编译器尚未实现，要么是不支持返回常量表达式。
测试所用的编译器版本：GCC v13.1.0，Clang v16.0.5
测试所用平台：Windows 11 x64
GCC和Clang都用-O0显式禁用优化，以保证测试中通过的函数在不开优化时也可以正常使用。
返回整数常量表达式或算术常量表达式的函数的测试代码如下：
所有函数都必须通过枚举常量（必须是整数常量表达式）和静态初始化器（必须是常量表达式）测试。
测试结果如下：
说实话，<complex.h>里面的复函数能出现在这里实在是大为出乎意料，因为这些函数真的很复杂，别说是返回常量表达式了，就算是用常规方法实现一个都殊为不易。
返回指针常量表达式的函数只能用于静态初始化器，它们的测试代码与上述大同小异，这类函数不需要通过枚举常量测试，只需要通过静态初始化器测试即可，结果如下：
以下标准头提供的库函数lz未进行测试，但从它们的功能来看大概率不行：
<fenv.h>, <setjmp.h>, <signal.h>, <stdatomic.h>
所有未列举于此的标准头和库函数，要么是编译器尚未实现，要么是不支持返回常量表达式。
测试所用的编译器版本：GCC v13.1.0，Clang v16.0.5
测试所用平台：Windows 11 x64
顶中顶 最后发表一点感想吧。
当初C99加入泛型宏的时候，并没有给予程序员编写泛型宏的能力，于是编译器纷纷各显神通，而程序员只得望洋兴叹，直到C11加入_Generic。C23最开始的constexpr提案野心勃勃，但很快就被一砍再砍，最后就只剩下了一个constexpr对象，这还不够，面对已经被削成渣的constexpr，标准还要为它附上各种不可理喻的限制，比如这个声明：
constexpr int a=1,b=2,c=3,d=4;
看起来没什么问题？对不起，C23请你把这四个对象分开来一行一个地声明。你问为什么不能连在一起？别问，问就是underspecified declaration。
幸好，GCC和Clang的存在让我们可以提前体验到constexpr函数的快乐，一如当初的泛型宏，就像一位高深莫测的魔法师，亲手向我们展示了魔法的神奇，却又悄悄地隐藏了背后的咒语。正是这种神奇驱动着程序员走上了找寻咒语的道路，并最终把咒语化作标准文档上的一段段文字，化作人人触手可及的现实。
期待着constexpr函数加入C语言标准的那一天。
EOF
当初C99加入泛型宏的时候，并没有给予程序员编写泛型宏的能力，于是编译器纷纷各显神通，而程序员只得望洋兴叹，直到C11加入_Generic。C23最开始的constexpr提案野心勃勃，但很快就被一砍再砍，最后就只剩下了一个constexpr对象，这还不够，面对已经被削成渣的constexpr，标准还要为它附上各种不可理喻的限制，比如这个声明：
constexpr int a=1,b=2,c=3,d=4;
看起来没什么问题？对不起，C23请你把这四个对象分开来一行一个地声明。你问为什么不能连在一起？别问，问就是underspecified declaration。
幸好，GCC和Clang的存在让我们可以提前体验到constexpr函数的快乐，一如当初的泛型宏，就像一位高深莫测的魔法师，亲手向我们展示了魔法的神奇，却又悄悄地隐藏了背后的咒语。正是这种神奇驱动着程序员走上了找寻咒语的道路，并最终把咒语化作标准文档上的一段段文字，化作人人触手可及的现实。
期待着constexpr函数加入C语言标准的那一天。
EOF
