XeO2 在十月接近尾声的时候，C23终于作为ISO/IEC 9899:2024正式发布了[lbk]1[rbk]。想起楼主去年元旦发的那个“盘点C23有趣的新特性”的帖子，不由得感慨这两年真是好事多磨。如今下一代C标准C2y已经起步一段时间了，今天楼主就挑选几个个人认为比较有意思的新特性来讲(shui)一讲(shui)盘点C23那些有趣的新特性
c语言吧 关注：798,678贴子：4,346,262
1. 范围case (N3370)[2]：
范围case肯定是一个大家都喜闻乐见的新特性
，所以把它放在最前面。
众所周知，在C里面判断一个整数的范围一般是用if，比如经典的分数转等级问题：
这种题目在用if做完之后一般还会问怎么用switch来做，这可就让不少同学犯难了，不过仔细观察不难发现，只要把分数除以10就可以缩小范围，接下来switch只需判断0到10就行了，倒也能解决，就是不像if那样简单自然。
这时候肯定很多人会想：要是case后面能写范围就好了
。
“谁说不能？”
随着一声巨响，N3370带着case-ranges闪亮登场了：
“我来到这里就是为了证明，switch可以比if更自然、更简洁！”，switch如是说道。
准确地说范围case也算不上什么新特性，毕竟它作为GNU扩展已经存在很长时间了，只不过现在终于被标准化了。
范围case肯定是一个大家都喜闻乐见的新特性
，所以把它放在最前面。众所周知，在C里面判断一个整数的范围一般是用if，比如经典的分数转等级问题：
这种题目在用if做完之后一般还会问怎么用switch来做，这可就让不少同学犯难了，不过仔细观察不难发现，只要把分数除以10就可以缩小范围，接下来switch只需判断0到10就行了，倒也能解决，就是不像if那样简单自然。
这时候肯定很多人会想：要是case后面能写范围就好了
。“谁说不能？”
随着一声巨响，N3370带着case-ranges闪亮登场了：
“我来到这里就是为了证明，switch可以比if更自然、更简洁！”，switch如是说道。
准确地说范围case也算不上什么新特性，毕竟它作为GNU扩展已经存在很长时间了，只不过现在终于被标准化了。
2. 获取数组长度的关键词 (N3369)[3]：
C有一个获得对象大小的关键词sizeof，这个关键词在malloc的参数里面很常用，因为它能获得对象的字节数。然而对于数组来说，我们不仅希望知道它的字节数，还希望知道它的长度，可是C却没有提供一个直接获取数组长度的方法，所以程序员一般会写一个这样的宏：
这样写循环遍历数组的时候就不用每次都写长长的一串了。
虽然这不失为一种解决问题的办法，但是其他编程语言基本都提供了便捷的方法获取数组的长度，C这么搞总让人感觉不是滋味儿。
好在C2y终于打算为这项功能添加一个关键词，它的用法跟sizeof一样，但参数只能是一个数组。现在这个关键词的具体行为已经基本确定了，然而C标准委员会却在为这个关键词起名上犯了难，他们做了很多调查，甚至发了问卷广泛征求意见，这个问卷大家也可以参与。
C有一个获得对象大小的关键词sizeof，这个关键词在malloc的参数里面很常用，因为它能获得对象的字节数。然而对于数组来说，我们不仅希望知道它的字节数，还希望知道它的长度，可是C却没有提供一个直接获取数组长度的方法，所以程序员一般会写一个这样的宏：
这样写循环遍历数组的时候就不用每次都写长长的一串了。
虽然这不失为一种解决问题的办法，但是其他编程语言基本都提供了便捷的方法获取数组的长度，C这么搞总让人感觉不是滋味儿。
好在C2y终于打算为这项功能添加一个关键词，它的用法跟sizeof一样，但参数只能是一个数组。现在这个关键词的具体行为已经基本确定了，然而C标准委员会却在为这个关键词起名上犯了难，他们做了很多调查，甚至发了问卷广泛征求意见，这个问卷大家也可以参与。
3. 高效字符串转换函数 (N3366)[4]：
这个提案我愿称之为神！
用一句话来概括，这个提案提供了一套完整的、可靠的、基于本地环境的、在char, wchar_t, UTF-8, UTF-16, UTF-32字符和字符串之间互相转换的函数！
N3366经历了整整13个版本，终于在这一次被C2y所接受，这是一场来之不易的伟大胜利[5]。
不出意外的话，从此之后，字符串字面量、scanf、printf会产生乱码的时代，要彻底结束了。
这些函数目前尚未被任何一个C标准库所实现，不过提案的作者自己已经将其实现了，可以在这里(https://ztdcuneicode.readthedocs.io/en/latest/)查看这个库的文档，其中也包含了库的GitHub链接。
JeanHeyd Meneide在cuneicode, and the Future of Text in C (https://thephd.dev/cuneicode-and-the-future-of-text-in-c)里面详细讲述了一切的来龙去脉，感兴趣的可以自行阅读。
接下来楼主会简要说明一下这个提案的重大意义究竟在哪里。
这个提案我愿称之为神！
用一句话来概括，这个提案提供了一套完整的、可靠的、基于本地环境的、在char, wchar_t, UTF-8, UTF-16, UTF-32字符和字符串之间互相转换的函数！
N3366经历了整整13个版本，终于在这一次被C2y所接受，这是一场来之不易的伟大胜利[5]。
不出意外的话，从此之后，字符串字面量、scanf、printf会产生乱码的时代，要彻底结束了。
这些函数目前尚未被任何一个C标准库所实现，不过提案的作者自己已经将其实现了，可以在这里(https://ztdcuneicode.readthedocs.io/en/latest/)查看这个库的文档，其中也包含了库的GitHub链接。
JeanHeyd Meneide在cuneicode, and the Future of Text in C (https://thephd.dev/cuneicode-and-the-future-of-text-in-c)里面详细讲述了一切的来龙去脉，感兴趣的可以自行阅读。
接下来楼主会简要说明一下这个提案的重大意义究竟在哪里。
作为一门历史悠久的语言，标准C对于字符编码的处理是非常混乱且无能的。
最开始C只有char这一种字符类型，那时候char只需要存储一些字母、数字和常用标点符号就行了，一个字节够用了。
然而事情很快起了变化，欧美以外的国家和地区也用上计算机了。像汉字这样的文字，常用字有一千以上，一个字节存不下，所以各国纷纷在ASCII的基础上制定了自己的编码标准。这些标准只考虑了自身情况，因此大多互不兼容。微软为了让自己的系统能支持各国语言，就搞了个东西叫做“代码页”，你的计算机在哪个地区，就切换到哪个地区的代码页，使用那个地区的编码，这显然是一种“头痛医头，脚痛医脚”的做法，在自己的机器上还好使，要是在不同地区的计算机之间传输文本，那就全乱套了。如果你在二三十年前玩过来自两岸三地的游戏，想必对此深有体会。
“代码页”埋下了混乱的种子，从此char存储的再也不是简单的单字节码，而是来自不同地区互不兼容的编码，这成为了日后一切混乱的根源。
这种混乱的局面肯定是无法长久的，后来ISO开始制定UCS，而施乐、苹果等商业公司则牵头建立了统一码联盟，幸好ISO和统一码联盟达成了共识，避免了“统一码”的分裂，这才有了我们今天看到的Unicode。
在这种背景下，C很识时务地加入了wchar_t类型，让我们看看C99是怎么说的：
好，很有精神！
彼时的UCS还是瘦小的UCS-2，wchar_t只要有两个字节就足以存下任何字符了，所以在当时C99的这种描述还不算有很大问题。
然而很快UCS-2也不够用了，这时Unicode果断打破了“基本多语种平面”(BMP)的限制，将字符集扩展成了UCS-4。
于是在一瞬间，wchar_t就成为了一个笑话，一个彻头彻尾的笑话。
为什么呢？因为微软，因为兼容性。
最开始C只有char这一种字符类型，那时候char只需要存储一些字母、数字和常用标点符号就行了，一个字节够用了。
然而事情很快起了变化，欧美以外的国家和地区也用上计算机了。像汉字这样的文字，常用字有一千以上，一个字节存不下，所以各国纷纷在ASCII的基础上制定了自己的编码标准。这些标准只考虑了自身情况，因此大多互不兼容。微软为了让自己的系统能支持各国语言，就搞了个东西叫做“代码页”，你的计算机在哪个地区，就切换到哪个地区的代码页，使用那个地区的编码，这显然是一种“头痛医头，脚痛医脚”的做法，在自己的机器上还好使，要是在不同地区的计算机之间传输文本，那就全乱套了。如果你在二三十年前玩过来自两岸三地的游戏，想必对此深有体会。
“代码页”埋下了混乱的种子，从此char存储的再也不是简单的单字节码，而是来自不同地区互不兼容的编码，这成为了日后一切混乱的根源。
这种混乱的局面肯定是无法长久的，后来ISO开始制定UCS，而施乐、苹果等商业公司则牵头建立了统一码联盟，幸好ISO和统一码联盟达成了共识，避免了“统一码”的分裂，这才有了我们今天看到的Unicode。
在这种背景下，C很识时务地加入了wchar_t类型，让我们看看C99是怎么说的：
好，很有精神！
彼时的UCS还是瘦小的UCS-2，wchar_t只要有两个字节就足以存下任何字符了，所以在当时C99的这种描述还不算有很大问题。
然而很快UCS-2也不够用了，这时Unicode果断打破了“基本多语种平面”(BMP)的限制，将字符集扩展成了UCS-4。
于是在一瞬间，wchar_t就成为了一个笑话，一个彻头彻尾的笑话。
为什么呢？因为微软，因为兼容性。
为什么要有wchar_t？那还不是为了跟上Unicode的步伐，解决字符编码混乱的问题，毕竟char已经被代码页搞得一团糟了，而wchar_t就是全村的希望。
UCS-2扩展成UCS-4之后，wchar_t就需要4个字节才能存下这么多字符了，但是微软表示：不，wchar_t在Windows上就是2字节，谁也不能改。
人家微软也是有理由的，我Windows NT好不容易从ANSI全面转向Unicode，系统API都把Unicode当作默认选项了，现在突然变成4字节，兼容性还要不要了？系统出了问题谁负责？
于是wchar_t在Windows上就一直是2字节了。
实际上微软已经算好的了，后来好歹是把wchar_t从UCS-2升级成了UTF-16，否则还不知道会出多少乱子。
其他制造商可就没有微软这么“良心”了，比如IBM的某些设备上wchar_t既不是UTF-16也不是UTF-32，而是和char一样的本地环境编码，只不过大小是2字节；还有些实现更懒，直接不支持额外的本地环境，wchar_t也是1字节。
你可能会说：“啊？”
其实没什么好惊讶的，看看C99对wchar_t的描述，它既没有要求这玩意儿是Unicode也没有要求这玩意儿至少有2字节，一切都取决于实现，那实现自然是怎么高兴怎么来啊。
wchar_t就这么成为了第二个char。
可是我们要wchar_t本来不就是希望你能像Unicode一样解决字符编码不统一的问题？现在你自己都不统一了，我要你有什么用？
你甚至连大小都不能确定呢，那我直接用char不是更香，人家好歹能确定是一个字节呢。
相比之下做得最好的要数Linux了，在今天常见的Linux发行版上，char通常是UTF-8编码，而wchar_t通常是4字节的UTF-32，可谓是清晰简洁明了。
UCS-2扩展成UCS-4之后，wchar_t就需要4个字节才能存下这么多字符了，但是微软表示：不，wchar_t在Windows上就是2字节，谁也不能改。
人家微软也是有理由的，我Windows NT好不容易从ANSI全面转向Unicode，系统API都把Unicode当作默认选项了，现在突然变成4字节，兼容性还要不要了？系统出了问题谁负责？
于是wchar_t在Windows上就一直是2字节了。
实际上微软已经算好的了，后来好歹是把wchar_t从UCS-2升级成了UTF-16，否则还不知道会出多少乱子。
其他制造商可就没有微软这么“良心”了，比如IBM的某些设备上wchar_t既不是UTF-16也不是UTF-32，而是和char一样的本地环境编码，只不过大小是2字节；还有些实现更懒，直接不支持额外的本地环境，wchar_t也是1字节。
你可能会说：“啊？”
其实没什么好惊讶的，看看C99对wchar_t的描述，它既没有要求这玩意儿是Unicode也没有要求这玩意儿至少有2字节，一切都取决于实现，那实现自然是怎么高兴怎么来啊。
wchar_t就这么成为了第二个char。
可是我们要wchar_t本来不就是希望你能像Unicode一样解决字符编码不统一的问题？现在你自己都不统一了，我要你有什么用？
你甚至连大小都不能确定呢，那我直接用char不是更香，人家好歹能确定是一个字节呢。相比之下做得最好的要数Linux了，在今天常见的Linux发行版上，char通常是UTF-8编码，而wchar_t通常是4字节的UTF-32，可谓是清晰简洁明了。
四条咸鱼 在此之后的很长一段时间，C程序员在处理字符编码的时候基本上是两眼一摸黑的，因为char在不同的平台上编码不统一，wchar_t在不同的平台上大小和编码都不统一，所以程序员要么回归原始的调用系统API的方式，要么基于对不同操作系统的“知识”写出针对不同操作系统的转换代码。在处理字符编码这一问题上，C的跨平台特性就这么被破坏殆尽了。
直到C11的出现，事情似乎终于迎来了一丝转机。
C11加入了char16_t和char32_t类型：
WG14终于聪明了一点，但不多。
说他们聪明了一点吧，是因为这次总算是记得限制类型的大小了；说不多吧，是因为他们还是不肯限制这两种类型的编码。要是实现把这两种类型当做大一点char或wchar_t来用，你WG14可是一点办法都没有呀。
值得庆幸的是，这种糟糕的事情最终并没有发生，而且C23终于是把这两种类型的编码确定为UTF-16和UTF-32了。
有了新的字符类型，自然要有相对应的转换函数了，它们一共有四个：mbrtoc16，c16rtomb，mbrtoc32，c32rtomb。
好的，现在我们来思考一下，如果我们有一个UTF-8编码的文本，要把它转换成本地环境编码在屏幕上打印出来，要怎么做呢？
首先UTF-8和UTF-16之间的转换是平凡的，因此我们很容易自己编写一个函数把UTF-8转换成UTF-16，然后再调用c16rtomb把UTF-16转换成char就完事了。
事情真的是这样吗？
当然不是。
如果你使用的是常见的Linux发行版，那么char的编码就是UTF-8，根本不需要任何转换。
如果你使用的是Windows……
啊？
这不是UTF-8吗？
啊啊啊啊？？？？？？？？！
直到C11的出现，事情似乎终于迎来了一丝转机。
C11加入了char16_t和char32_t类型：
WG14终于聪明了一点，但不多。
说他们聪明了一点吧，是因为这次总算是记得限制类型的大小了；说不多吧，是因为他们还是不肯限制这两种类型的编码。要是实现把这两种类型当做大一点char或wchar_t来用，你WG14可是一点办法都没有呀。
值得庆幸的是，这种糟糕的事情最终并没有发生，而且C23终于是把这两种类型的编码确定为UTF-16和UTF-32了。
有了新的字符类型，自然要有相对应的转换函数了，它们一共有四个：mbrtoc16，c16rtomb，mbrtoc32，c32rtomb。
好的，现在我们来思考一下，如果我们有一个UTF-8编码的文本，要把它转换成本地环境编码在屏幕上打印出来，要怎么做呢？
首先UTF-8和UTF-16之间的转换是平凡的，因此我们很容易自己编写一个函数把UTF-8转换成UTF-16，然后再调用c16rtomb把UTF-16转换成char就完事了。
事情真的是这样吗？
当然不是。
如果你使用的是常见的Linux发行版，那么char的编码就是UTF-8，根本不需要任何转换。
如果你使用的是Windows……
啊？
这不是UTF-8吗？
啊啊啊啊？？？？？？？？！
“这是怎么回事啊？！微软……”
“诺，这就是答案。”
那两个反过来的函数也是一样的。
跟C11的描述完全不一样：
C11貌似没有强调这个函数跟本地环境的关系，但是这里出现了MB_CUR_MAX宏：
这个宏显然是与本地环境有关的，所以c16rtomb的本意就是在char16_t和本地环境编码之间转换，而不是无视本地环境直接选择UTF-8。
这就是我们巨硬啊，巨巨又硬硬啊，直接对着C标准骑脸输出，你们有这样的公司么？
微软就这样狠狠地恶心了C程序员一把，C11的一切努力都白费了，跨平台的、在char和char16_t, char32_t之间的转换函数被微软这一手谜之操作搞得一塌糊涂，C程序员再次望向那高耸入云的巴别塔，只留徒然哀叹。
先别激动，因为我们接下来要介绍的这位，连c16rtomb都只能说是小丑见大丑。
“诺，这就是答案。”
那两个反过来的函数也是一样的。
跟C11的描述完全不一样：
C11貌似没有强调这个函数跟本地环境的关系，但是这里出现了MB_CUR_MAX宏：
这个宏显然是与本地环境有关的，所以c16rtomb的本意就是在char16_t和本地环境编码之间转换，而不是无视本地环境直接选择UTF-8。
这就是我们巨硬啊，巨巨又硬硬啊，直接对着C标准骑脸输出，你们有这样的公司么？
微软就这样狠狠地恶心了C程序员一把，C11的一切努力都白费了，跨平台的、在char和char16_t, char32_t之间的转换函数被微软这一手谜之操作搞得一塌糊涂，C程序员再次望向那高耸入云的巴别塔，只留徒然哀叹。
先别激动，因为我们接下来要介绍的这位，连c16rtomb都只能说是小丑见大丑。
“出来吧，mbrtowc”
它跟mbrtoc16和mbrtoc32有什么不同呢？
没错，除了编码之外它们最主要的区别在于，mbrtowc只考虑了用一个wchar_t对象存储结果的情况。
-
哈哈哈哈，哈哈哈哈哈哈，C标准向全世界放了一个响亮的屁，比司马懿在洛水边上放的那个还要响。一个wchar_t存储结果？一个char32_t都做不到！
-
且不要说像Windows这样wchar_t是2字节编码是UTF-16的根本没法用一个表示扩展平面的字符，就算是Linux那4字节编码是UTF-32的，也做不到！
-
“不可能，绝对不可能！UTF-32不是能表示所有Unicode字符吗？一个char32_t怎么可能不够用？”
“是吗？”
现在，就让我们一起亲手击碎对UTF-32的最后一点幻想吧。
安装了VS Code的同学，可以跟着楼主一起尝试以下步骤：
首先安装一个Hex Editor扩展，然后新建一个文本文件，右键Open With...，
选择用“Hex Editor”打开，
点击“+”号，输入88 62，保存。
关掉这个文件再重新打开，看到一个乱码，
不用担心，点击底部的UTF-8，在顶部选择“Reopen with Encoding”，
选择Big5-HKSCS。
它跟mbrtoc16和mbrtoc32有什么不同呢？
没错，除了编码之外它们最主要的区别在于，mbrtowc只考虑了用一个wchar_t对象存储结果的情况。
-
哈哈哈哈，哈哈哈哈哈哈，C标准向全世界放了一个响亮的屁，比司马懿在洛水边上放的那个还要响。一个wchar_t存储结果？一个char32_t都做不到！
-
且不要说像Windows这样wchar_t是2字节编码是UTF-16的根本没法用一个表示扩展平面的字符，就算是Linux那4字节编码是UTF-32的，也做不到！
-
“不可能，绝对不可能！UTF-32不是能表示所有Unicode字符吗？一个char32_t怎么可能不够用？”
“是吗？”
现在，就让我们一起亲手击碎对UTF-32的最后一点幻想吧。
安装了VS Code的同学，可以跟着楼主一起尝试以下步骤：
首先安装一个Hex Editor扩展，然后新建一个文本文件，右键Open With...，
选择用“Hex Editor”打开，
点击“+”号，输入88 62，保存。
关掉这个文件再重新打开，看到一个乱码，
不用担心，点击底部的UTF-8，在顶部选择“Reopen with Encoding”，
选择Big5-HKSCS。
