c语言吧 关注：799,003贴子：4,352,959
XeO2
）。
02. auto
auto在C和C++里面的地位可谓是天差地别。C++的auto是一个功能强大且实用的关键词，而C的auto则完全是一个吉祥物。N2176当中auto出现的次数寥寥无几，6.7.1 Storage-class specifiers一节中甚至完全没有提及任何与auto相关的内容（好吧，auto的名字被列了出来，这算不算？），auto实惨。
幸好，随着C23的到来，auto再也不是吉祥物了，因为auto终于具有了最基础的类型推导功能：根据初始化器自动推导声明变量的类型。嗯，好吧，是有作用了，但不多，而且我觉得这大概是一个我用不上的新特性，因为我还是喜欢手动写上每一个变量的类型，至少在我看来，这样的代码更清楚，阅读起也来更容易。
这是N2176 6.7.1 Storage-class specifiers的第4小节：
到了n3054，这里的内容就丰富了起来：
可以看到最后已经出现了与类型推导相关的描述。
不仅如此，在第7小节中，关于auto和类型推导的描述又出现了一遍：
这还不是最重要的，因为C23单独为auto增加了独属于它的一节：6.7.9 Type inference
auto排面！
auto在C和C++里面的地位可谓是天差地别。C++的auto是一个功能强大且实用的关键词，而C的auto则完全是一个吉祥物。N2176当中auto出现的次数寥寥无几，6.7.1 Storage-class specifiers一节中甚至完全没有提及任何与auto相关的内容（好吧，auto的名字被列了出来，这算不算？），auto实惨。
幸好，随着C23的到来，auto再也不是吉祥物了，因为auto终于具有了最基础的类型推导功能：根据初始化器自动推导声明变量的类型。嗯，好吧，是有作用了，但不多，而且我觉得这大概是一个我用不上的新特性，因为我还是喜欢手动写上每一个变量的类型，至少在我看来，这样的代码更清楚，阅读起也来更容易。
这是N2176 6.7.1 Storage-class specifiers的第4小节：
到了n3054，这里的内容就丰富了起来：
可以看到最后已经出现了与类型推导相关的描述。
不仅如此，在第7小节中，关于auto和类型推导的描述又出现了一遍：
这还不是最重要的，因为C23单独为auto增加了独属于它的一节：6.7.9 Type inference
auto排面！
03. bool, false和true
布尔类型实在是一个相当基础的类型，以至于如果一门编程语言不提供它，那看起来真是非常不可思议。令人惊讶的是，C语言直到C99才加入了_Bool类型，这时候距离C语言诞生已经过去了二十多年。时光荏苒，24年又过去了，bool终于摆脱了_Bool这么个不伦不类的名字，迎回了本该属于它的名字：bool。至于_Bool这个丑八怪为什么能存在这么多年，原因当然是C标准委员会不想破坏既存的代码，毕竟早年间typedef char bool;或者typedef int bool;的程序员应该不在少数，如果bool直接升格成关键词，这些代码将无一幸免。在强迫症和程序员的头发之间，C标准委员会最终决定照顾程序员的头发。幸而时间终究会逐渐抹去那些错误的代码，bool也终于等来了它的正名之日。
false和true也是在C99加入的，长期以来它们以宏的形式存在于<stdbool.h>中，堪称有名字的0和1（是的，它们的类型甚至不是_Bool，而是int），现在它们终于也晋升为关键词了。
bool, false和true成为关键词对于C程序员来说应该是一件喜大普奔的事，毕竟使用bool这么基础的特性还要带上一个<stdbool.h>真是一件相当别扭的事情。
话说回来，其实bool, false和true成为关键词并不能改变什么，因为……
bool：我升职啦！现在我是关键词了。
&&, ||, !, ==, !=, <, <=, >, >=：（漫不经心地）哦。
bool：让我们做朋友吧！
&&, ||, !, ==, !=, <, <=, >, >=：（无语）想啥呢？咱们呐，是鸡犬之声相闻，老死不相往来。我们和int才是好朋友，我们的返回值类型都是它，你应该去找false和true，它们才是你的朋友呢。
是啊，int才是光芒万丈的太阳，bool不过是微弱的萤火之光罢了，怎能妄想争夺int的宝座？
bool站在<stdbool.h>的废墟上，太阳照耀着bool的身体，这是一个旧时代的落幕，也是一个新时代的开始，bool坚信，未来是属于自己的。
（n3054中对<stdbool.h>的描述，除了一个废弃的宏以外，已然空空如也）
布尔类型实在是一个相当基础的类型，以至于如果一门编程语言不提供它，那看起来真是非常不可思议。令人惊讶的是，C语言直到C99才加入了_Bool类型，这时候距离C语言诞生已经过去了二十多年。时光荏苒，24年又过去了，bool终于摆脱了_Bool这么个不伦不类的名字，迎回了本该属于它的名字：bool。至于_Bool这个丑八怪为什么能存在这么多年，原因当然是C标准委员会不想破坏既存的代码，毕竟早年间typedef char bool;或者typedef int bool;的程序员应该不在少数，如果bool直接升格成关键词，这些代码将无一幸免。在强迫症和程序员的头发之间，C标准委员会最终决定照顾程序员的头发。幸而时间终究会逐渐抹去那些错误的代码，bool也终于等来了它的正名之日。
false和true也是在C99加入的，长期以来它们以宏的形式存在于<stdbool.h>中，堪称有名字的0和1（是的，它们的类型甚至不是_Bool，而是int），现在它们终于也晋升为关键词了。
bool, false和true成为关键词对于C程序员来说应该是一件喜大普奔的事，毕竟使用bool这么基础的特性还要带上一个<stdbool.h>真是一件相当别扭的事情。
话说回来，其实bool, false和true成为关键词并不能改变什么，因为……
bool：我升职啦！现在我是关键词了。
&&, ||, !, ==, !=, <, <=, >, >=：（漫不经心地）哦。
bool：让我们做朋友吧！
&&, ||, !, ==, !=, <, <=, >, >=：（无语）想啥呢？咱们呐，是鸡犬之声相闻，老死不相往来。我们和int才是好朋友，我们的返回值类型都是它，你应该去找false和true，它们才是你的朋友呢。
是啊，int才是光芒万丈的太阳，bool不过是微弱的萤火之光罢了，怎能妄想争夺int的宝座？
bool站在<stdbool.h>的废墟上，太阳照耀着bool的身体，这是一个旧时代的落幕，也是一个新时代的开始，bool坚信，未来是属于自己的。
（n3054中对<stdbool.h>的描述，除了一个废弃的宏以外，已然空空如也）
04. constexpr
终于轮到我最喜欢的关键词了，我真是爱死constexpr了。
对于C++程序员来说，constexpr是老熟人了，现在这位熟悉的陌生人终于加入到了C语言的大家庭中。在此之前，C语言里面有名字的常量只有两种：宏常量和枚举常量。宏常量和枚举常量各有局限，宏常量只是预处理时的文本替换，它根本就不是一个对象，所以不能用&取地址，枚举常量只能是整数类型，而且枚举的本意是在有限个情况的组合中选择一种，如果把一堆不相干的常量凑进一个enum里面，那会显得很奇怪。至于const，它是“只读”而不是“常量”，所以const限定的变量根本不能当常量来用。
之前尝试把C++标准库的mersenne_twister_engine搬进C语言里面，然后就遇到了问题。首先梅森旋转器有一个参数n，表示引擎状态数，对于32位梅森旋转器来说n=624，我把n声明成一个全局变量：
static const size_t n=624;
梅森旋转器可以用种子序列初始化，这需要一个大小为n的数组，在函数内部声明如下：
uint_fast32_t a[n];
然后烦人的Clang就会给你一个讨厌的Wvla警告，这还算好的，换成MSVC的话编译都过不了。
可是我真的没有想用VLA啊，static变量的初始化器必须是常量表达式，而const意味着n不可修改，所以n是一个“事实上的编译时常量”，可惜n没有常量的名分，因此不能把它当成常量来用。
有人可能会说：你用#define n 624不就好了嘛？额，也不是不行，不过我把函数都写成了static inline的形式放在了头文件里面，所以全部的代码就是一个头文件，如果用宏常量的话，以后包含了这个头文件的代码都不能用n这个名字了，这个代价似乎有点大。
为什么我如此喜爱constexpr？因为它完美地解决了上面那个问题，同样是全局变量：
constexpr size_t n=624;
这样声明出来的n是一个真正的常量，用这个n声明的数组也不再是VLA了。
有趣的是，const属于限定符，而constexpr则是存储类说明符：
constexpr可以和auto, register或static组合在一起：
和一般的文件作用域变量不同，文件作用域里面带有constexpr的标识符具有内部链接，类似于static：
constexpr隐含了const限定符，这很合理：
跟C++花样繁多的constexpr比起来，C的constexpr只是实现了最基础的声明常量的功能，不过就这一点我已经很满意了。
终于轮到我最喜欢的关键词了，我真是爱死constexpr了。
对于C++程序员来说，constexpr是老熟人了，现在这位熟悉的陌生人终于加入到了C语言的大家庭中。在此之前，C语言里面有名字的常量只有两种：宏常量和枚举常量。宏常量和枚举常量各有局限，宏常量只是预处理时的文本替换，它根本就不是一个对象，所以不能用&取地址，枚举常量只能是整数类型，而且枚举的本意是在有限个情况的组合中选择一种，如果把一堆不相干的常量凑进一个enum里面，那会显得很奇怪。至于const，它是“只读”而不是“常量”，所以const限定的变量根本不能当常量来用。
之前尝试把C++标准库的mersenne_twister_engine搬进C语言里面，然后就遇到了问题。首先梅森旋转器有一个参数n，表示引擎状态数，对于32位梅森旋转器来说n=624，我把n声明成一个全局变量：
static const size_t n=624;
梅森旋转器可以用种子序列初始化，这需要一个大小为n的数组，在函数内部声明如下：
uint_fast32_t a[n];
然后烦人的Clang就会给你一个讨厌的Wvla警告，这还算好的，换成MSVC的话编译都过不了。
可是我真的没有想用VLA啊，static变量的初始化器必须是常量表达式，而const意味着n不可修改，所以n是一个“事实上的编译时常量”，可惜n没有常量的名分，因此不能把它当成常量来用。
有人可能会说：你用#define n 624不就好了嘛？额，也不是不行，不过我把函数都写成了static inline的形式放在了头文件里面，所以全部的代码就是一个头文件，如果用宏常量的话，以后包含了这个头文件的代码都不能用n这个名字了，这个代价似乎有点大。
为什么我如此喜爱constexpr？因为它完美地解决了上面那个问题，同样是全局变量：
constexpr size_t n=624;
这样声明出来的n是一个真正的常量，用这个n声明的数组也不再是VLA了。
有趣的是，const属于限定符，而constexpr则是存储类说明符：
constexpr可以和auto, register或static组合在一起：
和一般的文件作用域变量不同，文件作用域里面带有constexpr的标识符具有内部链接，类似于static：
constexpr隐含了const限定符，这很合理：
跟C++花样繁多的constexpr比起来，C的constexpr只是实现了最基础的声明常量的功能，不过就这一点我已经很满意了。
05. nullptr
顾名思义，nullptr是空指针常量。在C23中，nullptr和false, true同属于预定义常量(Predefined constants)。为什么要叫“预定义常量”？我很疑惑。n3054对预定义常量是这样描述的：
难道说，用关键词表示的常量就叫预定义常量？
有人可能会好奇：C不是有NULL么？既然NULL就是空指针常量，为什么又来一个nullptr表示空指针常量？岂不闻一山不容二虎？开始我也是这么认为的，直到我看了n3042，它给出了几条令我无法拒绝的理由，简单概括如下：
1st：C标准对NULL太过宽容。C语言的NULL可以展开成0, 0L（与C++兼容）或者((void*)0)（常见实现），通常的编译器为了兼顾C和C++，在头文件里面对NULL的定义往往是这样的：
#ifdef __cplusplus
#define NULL 0
#else
#define NULL ((void*)0)
#endif
一般情况下，NULL的类型应该是void*，因为C语言的void*可以隐式转换成其他类型的指针，而且void*可以保证NULL准确地具有指针类型的宽度。遗憾的是，上述这一切是无法保证的，因为编译器可以把NULL展开为0，虽然0也可以隐式转换成任何类型的指针，但是在常见的64位平台上，int和void*拥有不同的宽度，这可能会导致严重的问题，最显而易见的是变参数函数，在这种情况下0不会隐式转换为指针，从而导致调用va_arg时得到错误的结果。
2nd：C标准委员会不愿意收紧对NULL的要求。把NULL强制规定为((void*)0)是一个美好的想法，可惜办不到。
3rd：因为NULL可以是int类型或者void*类型，所以当_Generic遇到NULL时可能会产生糟糕的结果。
4th：nullptr具有独特的nullptr_t类型，配合_Generic可以很容易地区分出空指针和有效指针，而((void*)0)不能保证在所有情况下都能和_Generic达成同样的效果。
nullptr主要具有三点理想的特性：拥有和指针类型相同的宽度，拥有与void*类型的空指针常量相同的表示，拥有独一无二的类型nullptr_t。这保证了nullptr可以安全地传递给变参数函数，而且可以通过_Generic很容易地和一般的指针区分开来。
（n3054 7.21.2 The nullptr_t type一节，描述了nullptr和nullptr_t的部分性质）
既然谈到了nullptr，自然是绕不开那个与它紧密相连的nullptr_t。直觉上我们可能会觉得应该是先有某种类型，然后才会有这种类型的常量，而nullptr_t则反其道而行之，它的定义是这样的：
颇有一种曹丕尊曹操为皇帝——儿子产生老子的感觉。
有了nullptr之后，NULL的展开形式又多了一种选择，那就是直接展开成nullptr，然而这仍然是无法保证的。至少于我而言，以后放弃NULL转而使用nullptr是肯定的了。不知道是否终有一日nullptr会彻底取代NULL。
顾名思义，nullptr是空指针常量。在C23中，nullptr和false, true同属于预定义常量(Predefined constants)。为什么要叫“预定义常量”？我很疑惑。n3054对预定义常量是这样描述的：
难道说，用关键词表示的常量就叫预定义常量？
有人可能会好奇：C不是有NULL么？既然NULL就是空指针常量，为什么又来一个nullptr表示空指针常量？岂不闻一山不容二虎？开始我也是这么认为的，直到我看了n3042，它给出了几条令我无法拒绝的理由，简单概括如下：
1st：C标准对NULL太过宽容。C语言的NULL可以展开成0, 0L（与C++兼容）或者((void*)0)（常见实现），通常的编译器为了兼顾C和C++，在头文件里面对NULL的定义往往是这样的：
#ifdef __cplusplus
#define NULL 0
#else
#define NULL ((void*)0)
#endif
一般情况下，NULL的类型应该是void*，因为C语言的void*可以隐式转换成其他类型的指针，而且void*可以保证NULL准确地具有指针类型的宽度。遗憾的是，上述这一切是无法保证的，因为编译器可以把NULL展开为0，虽然0也可以隐式转换成任何类型的指针，但是在常见的64位平台上，int和void*拥有不同的宽度，这可能会导致严重的问题，最显而易见的是变参数函数，在这种情况下0不会隐式转换为指针，从而导致调用va_arg时得到错误的结果。
2nd：C标准委员会不愿意收紧对NULL的要求。把NULL强制规定为((void*)0)是一个美好的想法，可惜办不到。
3rd：因为NULL可以是int类型或者void*类型，所以当_Generic遇到NULL时可能会产生糟糕的结果。
4th：nullptr具有独特的nullptr_t类型，配合_Generic可以很容易地区分出空指针和有效指针，而((void*)0)不能保证在所有情况下都能和_Generic达成同样的效果。
nullptr主要具有三点理想的特性：拥有和指针类型相同的宽度，拥有与void*类型的空指针常量相同的表示，拥有独一无二的类型nullptr_t。这保证了nullptr可以安全地传递给变参数函数，而且可以通过_Generic很容易地和一般的指针区分开来。
（n3054 7.21.2 The nullptr_t type一节，描述了nullptr和nullptr_t的部分性质）
既然谈到了nullptr，自然是绕不开那个与它紧密相连的nullptr_t。直觉上我们可能会觉得应该是先有某种类型，然后才会有这种类型的常量，而nullptr_t则反其道而行之，它的定义是这样的：
颇有一种曹丕尊曹操为皇帝——儿子产生老子的感觉。
有了nullptr之后，NULL的展开形式又多了一种选择，那就是直接展开成nullptr，然而这仍然是无法保证的。至少于我而言，以后放弃NULL转而使用nullptr是肯定的了。不知道是否终有一日nullptr会彻底取代NULL。
草酱
08. typeof和typeof_unqual
如果让我用一句话来评价typeof和typeof_unqual，那必须是“期望越大，失望越大”。
n3054对typeof和typeof_unqual的描述如下：
从已有类型声明出变量这种事情我们是司空见惯了，typeof则是反过来，从表达式得到一个类型（也可以从类型到类型，我变我自己），typeof_unqual更进一步，它可以脱掉顶层的cvr限定符和原子属性。
typeof本该是一个很好的新特性，它总让我不由得想到另一个东西：_Generic。
_Generic绝对是一个气死强迫症的半吊子设计，_Generic这个丑不拉几的名字就不说了，它的整个语法也是莫名其妙，跟C++的函数重载和模板函数比起来，_Generic简直就是一个（无法用语言形容的）乐色。要不是预处理指令做不到_Generic能做的事情，鬼都不会去用这破玩意儿。
我不知道有多少人会把_Generic当成是一种预处理特性，毕竟在_Generic的大本营<tgmath.h>里面，_Generic就总是和#define出现在一起，也难怪，_Generic的诞生就是为了给<tgmath.h>的泛型宏提供一种标准化的实现方法，也让程序员具有写泛型宏的能力，弄得_Generic好像必须和宏出现在一起似的。直到我仔细看了标准对_Generic的描述，才惊讶地发现：哦，原来这玩意儿是一个表达式啊？它居然是一个表达式？
_Generic就像是类型版本的switch。假设T只能是int, long, float和double其中之一，有如下代码：
当然一般情况下会把这团_Generic做成一个宏：
如果typeof具有我想象中的特性……好吧，如果真的有如果的话，上面那段代码可以写成这样：
直接利用已有的运算符，岂不美哉？
“不对！”有人可能会说，“条件运算符的后两个操作数不是随便什么类型都能组合在一起的。”嗯，很有道理，不过只要加上两条限制就可以解决这个小小的bug：
1st：条件运算符的条件要么是类型判断的组合，要么是正常的表达式；
2nd：如果条件运算符的条件是类型判断的组合，那么条件运算符的结果是可以在编译时确定的，这时条件运算符的类型和值就是被选择的分支的类型和值，未被选择的分支则完全不生成代码。
也许上述abs的例子看不出来后一种写法有什么优势，然而如果需要判断类型的参数不止一个，情况就不一样了。
<math.h>的fmax函数有两个double类型的参数x和y，它有对应的float和long double版本，以及一个同名的泛型宏。因为有两个参数，所以这个泛型宏通常的做法是把x和y加起来，利用隐式转换找到x和y的公共类型，然后再用_Generic判断这个公共类型。把x和y加起来再判断typeof自然也能做到，typeof甚至能做到单独判断x和y的类型，这点让_Generic来做可就不是那么容易了。
如果说x和y都是整数或浮点数还能用x+y来投机取巧的话，那么把参数类型换成指针可就算是把_Generic逼到墙角了。假设有四个函数：
char *sscat(char *s1, const char *s2);
char *swcat(char *s1, const wchar_t *s2);
wchar_t *wscat(wchar_t *s1, const char *s2);
wchar_t *wwcat(wchar_t *s1, const wchar_t *s2);
现在要设计泛型宏cat涵盖以上四个函数，怎么做？（请问_Generic，你不会想把s1和s2这两个指针加起来找公共类型吧？）
typeof拍着胸脯表示：“掌握之中，岂可逃之？”几行代码顺势而出：
（最后的nullptr是没有问题的，毕竟没有default的_Generic在匹配失败的情况下也会产生编译错误）
_Generic当然也能实现同样的功能，只要把两重_Generic套娃在一起就可以了，不过这样子的话，写出来的代码可能会不太好看。
可惜以上的一切都只是虚幻的想象，typeof不过是一个类型说明符，它根本就不是表达式，所以自然不能写typeof(x)==int这种代码。唉，说了这么多，不过是一场梦罢了，typeof终究不是炫酷的变形金刚，它只想安静地做一辆普普通通的玩具车。
如果让我用一句话来评价typeof和typeof_unqual，那必须是“期望越大，失望越大”。
n3054对typeof和typeof_unqual的描述如下：
从已有类型声明出变量这种事情我们是司空见惯了，typeof则是反过来，从表达式得到一个类型（也可以从类型到类型，我变我自己），typeof_unqual更进一步，它可以脱掉顶层的cvr限定符和原子属性。
typeof本该是一个很好的新特性，它总让我不由得想到另一个东西：_Generic。
_Generic绝对是一个气死强迫症的半吊子设计，_Generic这个丑不拉几的名字就不说了，它的整个语法也是莫名其妙，跟C++的函数重载和模板函数比起来，_Generic简直就是一个（无法用语言形容的）乐色。要不是预处理指令做不到_Generic能做的事情，鬼都不会去用这破玩意儿。
我不知道有多少人会把_Generic当成是一种预处理特性，毕竟在_Generic的大本营<tgmath.h>里面，_Generic就总是和#define出现在一起，也难怪，_Generic的诞生就是为了给<tgmath.h>的泛型宏提供一种标准化的实现方法，也让程序员具有写泛型宏的能力，弄得_Generic好像必须和宏出现在一起似的。直到我仔细看了标准对_Generic的描述，才惊讶地发现：哦，原来这玩意儿是一个表达式啊？它居然是一个表达式？
_Generic就像是类型版本的switch。假设T只能是int, long, float和double其中之一，有如下代码：
当然一般情况下会把这团_Generic做成一个宏：
如果typeof具有我想象中的特性……好吧，如果真的有如果的话，上面那段代码可以写成这样：
直接利用已有的运算符，岂不美哉？
“不对！”有人可能会说，“条件运算符的后两个操作数不是随便什么类型都能组合在一起的。”嗯，很有道理，不过只要加上两条限制就可以解决这个小小的bug：
1st：条件运算符的条件要么是类型判断的组合，要么是正常的表达式；
2nd：如果条件运算符的条件是类型判断的组合，那么条件运算符的结果是可以在编译时确定的，这时条件运算符的类型和值就是被选择的分支的类型和值，未被选择的分支则完全不生成代码。
也许上述abs的例子看不出来后一种写法有什么优势，然而如果需要判断类型的参数不止一个，情况就不一样了。
<math.h>的fmax函数有两个double类型的参数x和y，它有对应的float和long double版本，以及一个同名的泛型宏。因为有两个参数，所以这个泛型宏通常的做法是把x和y加起来，利用隐式转换找到x和y的公共类型，然后再用_Generic判断这个公共类型。把x和y加起来再判断typeof自然也能做到，typeof甚至能做到单独判断x和y的类型，这点让_Generic来做可就不是那么容易了。
如果说x和y都是整数或浮点数还能用x+y来投机取巧的话，那么把参数类型换成指针可就算是把_Generic逼到墙角了。假设有四个函数：
char *sscat(char *s1, const char *s2);
char *swcat(char *s1, const wchar_t *s2);
wchar_t *wscat(wchar_t *s1, const char *s2);
wchar_t *wwcat(wchar_t *s1, const wchar_t *s2);
现在要设计泛型宏cat涵盖以上四个函数，怎么做？（请问_Generic，你不会想把s1和s2这两个指针加起来找公共类型吧？）
typeof拍着胸脯表示：“掌握之中，岂可逃之？”几行代码顺势而出：
（最后的nullptr是没有问题的，毕竟没有default的_Generic在匹配失败的情况下也会产生编译错误）
_Generic当然也能实现同样的功能，只要把两重_Generic套娃在一起就可以了，不过这样子的话，写出来的代码可能会不太好看。
可惜以上的一切都只是虚幻的想象，typeof不过是一个类型说明符，它根本就不是表达式，所以自然不能写typeof(x)==int这种代码。唉，说了这么多，不过是一场梦罢了，typeof终究不是炫酷的变形金刚，它只想安静地做一辆普普通通的玩具车。
09. _BitInt
虽然_BitInt的名字是我讨厌的保留字形态，但是_BitInt实在是太有意思了，瑕不掩瑜，完全无法阻挡我对它的喜爱之情。
前面介绍的关键词，无外乎改名“转正”的，或是新鲜出炉的。_BitInt和它们不同，它本来叫做_ExtInt，是Clang的一个拓展，现在被吸纳到了标准中，属于是标准承认既存实现了。
n3054 6.7.2 Type specifiers一节对_BitInt有如下描述：
和一般的类型说明符不同，_BitInt需要一个额外的整数常量表达式共同构成最终的类型，比如_BitInt(32), _BitInt(64)等等。
_BitInt让我爱不释手，自然是因为它有着独特的魅力。C没有严格规定各种类型的宽度，只是给一些类型定下了最低要求，毕竟C要照顾不同的硬件。以整数类型为例：short和int至少是16位，long至少是32位，long long至少是64位。当然，在所有宽度定义之中，最重要的还得数CHAR_BIT，它至少是8。CHAR_BIT代表着一个字节的位宽度，字节是如此的基础，CHAR_BIT的重要性自然不言而喻。
在常见的PC平台上，我们可以假设CHAR_BIT等于8，short是2字节，int是4字节，long是4或8字节，long long是8字节。但是，谁知道这个世界上存在什么古灵精怪的硬件呢？既然C标准没有强求，那么CHAR_BIT等于16, 32自然是没有问题的，甚至12, 24这种非2的整次幂也不是不行，既然如此，short, int之类的也不是非得16位，32位了，short完全可以是24位，int是36位，long是48位……如果程序员一开始就假定了各种类型的宽度，那么由此而生的代码在遇到奇葩硬件的时候，是不是会出问题呢？
C99提供了定宽整数类型，<stdint.h>以typedef的形式提供了int8_t, int16_t等准确宽度的整数类型，C语言的世界似乎又重新美好了起来，直到……
关键在于第3点，如果实现提供特定宽度的整数类型，它应该定义相应的类型名，也就是说，如果实现不提供8位和16位的整数类型，它完全可以不定义int8_t和int16_t，怎么样，惊不惊喜？意不意外？
这时候就轮到_BitInt闪亮登场了。“无所谓，我会出手。”_BitInt如是说。
从此以后，定宽整数对程序员而言可谓是信手拈来：
typedef unsigned _BitInt(8) u8;
typedef unsigned _BitInt(16) u16;
在算术运算和位运算中，u8和u16的表现就像准确的8位和16位无符号整数一样，会在预想的情况中按预期的方式溢出，不会显露出任何多余的位（当然，用sizeof检查字节数和用unsigned char*查看对象表示就另当别论了）。因为_BitInt的最大位宽度是BITINT_MAXWIDTH，而BITINT_MAXWIDTH至少是ULLONG_WIDTH，后者又至少是64，所以你可以放心地定义任何你喜欢的64位以内的_BitInt。
值得注意的是，_BitInt的加入并不意味着<stdint.h>可以typedef _BitInt(8) int8_t;，事实上，C标准委员会是反对这一点的，从n3035可以一见端倪，所以，如果signed char不是8位，int8_t仍然可以不存在。
_BitInt是如此的光鲜亮丽，可是一切真的像_BitInt的外表这般美好吗？不是。在_BitInt收获鲜花和掌声的舞台背后，是编译器在做牛做马。如果声明一个_BitInt(19)或者_BitInt(53)之类的变量，那么CPU自然是不存在什么19位53位的通用寄存器的，内存中也不存在恰好是19位或53位的若干个字节，这种时候就只能靠编译器生成额外的代码，把这些“奇形怪状”的_BitInt放进一个稍大一点的存储单元里，并且在需要的时候设置好那些多余的位。
总而言之，我觉得_BitInt是一个很好的新特性，尤其是在你需要一个准确宽度的整数的时候，它是那么的简单又那么的好用，实在是让人找不到拒绝它的理由。
虽然_BitInt的名字是我讨厌的保留字形态，但是_BitInt实在是太有意思了，瑕不掩瑜，完全无法阻挡我对它的喜爱之情。
前面介绍的关键词，无外乎改名“转正”的，或是新鲜出炉的。_BitInt和它们不同，它本来叫做_ExtInt，是Clang的一个拓展，现在被吸纳到了标准中，属于是标准承认既存实现了。
n3054 6.7.2 Type specifiers一节对_BitInt有如下描述：
和一般的类型说明符不同，_BitInt需要一个额外的整数常量表达式共同构成最终的类型，比如_BitInt(32), _BitInt(64)等等。
_BitInt让我爱不释手，自然是因为它有着独特的魅力。C没有严格规定各种类型的宽度，只是给一些类型定下了最低要求，毕竟C要照顾不同的硬件。以整数类型为例：short和int至少是16位，long至少是32位，long long至少是64位。当然，在所有宽度定义之中，最重要的还得数CHAR_BIT，它至少是8。CHAR_BIT代表着一个字节的位宽度，字节是如此的基础，CHAR_BIT的重要性自然不言而喻。
在常见的PC平台上，我们可以假设CHAR_BIT等于8，short是2字节，int是4字节，long是4或8字节，long long是8字节。但是，谁知道这个世界上存在什么古灵精怪的硬件呢？既然C标准没有强求，那么CHAR_BIT等于16, 32自然是没有问题的，甚至12, 24这种非2的整次幂也不是不行，既然如此，short, int之类的也不是非得16位，32位了，short完全可以是24位，int是36位，long是48位……如果程序员一开始就假定了各种类型的宽度，那么由此而生的代码在遇到奇葩硬件的时候，是不是会出问题呢？
C99提供了定宽整数类型，<stdint.h>以typedef的形式提供了int8_t, int16_t等准确宽度的整数类型，C语言的世界似乎又重新美好了起来，直到……
关键在于第3点，如果实现提供特定宽度的整数类型，它应该定义相应的类型名，也就是说，如果实现不提供8位和16位的整数类型，它完全可以不定义int8_t和int16_t，怎么样，惊不惊喜？意不意外？
这时候就轮到_BitInt闪亮登场了。“无所谓，我会出手。”_BitInt如是说。
从此以后，定宽整数对程序员而言可谓是信手拈来：
typedef unsigned _BitInt(8) u8;
typedef unsigned _BitInt(16) u16;
在算术运算和位运算中，u8和u16的表现就像准确的8位和16位无符号整数一样，会在预想的情况中按预期的方式溢出，不会显露出任何多余的位（当然，用sizeof检查字节数和用unsigned char*查看对象表示就另当别论了）。因为_BitInt的最大位宽度是BITINT_MAXWIDTH，而BITINT_MAXWIDTH至少是ULLONG_WIDTH，后者又至少是64，所以你可以放心地定义任何你喜欢的64位以内的_BitInt。
值得注意的是，_BitInt的加入并不意味着<stdint.h>可以typedef _BitInt(8) int8_t;，事实上，C标准委员会是反对这一点的，从n3035可以一见端倪，所以，如果signed char不是8位，int8_t仍然可以不存在。
_BitInt是如此的光鲜亮丽，可是一切真的像_BitInt的外表这般美好吗？不是。在_BitInt收获鲜花和掌声的舞台背后，是编译器在做牛做马。如果声明一个_BitInt(19)或者_BitInt(53)之类的变量，那么CPU自然是不存在什么19位53位的通用寄存器的，内存中也不存在恰好是19位或53位的若干个字节，这种时候就只能靠编译器生成额外的代码，把这些“奇形怪状”的_BitInt放进一个稍大一点的存储单元里，并且在需要的时候设置好那些多余的位。
总而言之，我觉得_BitInt是一个很好的新特性，尤其是在你需要一个准确宽度的整数的时候，它是那么的简单又那么的好用，实在是让人找不到拒绝它的理由。
