c – 在编译时解析(u)int_fastX_t

不,标准不允许这样做.请记住,对于此特定区域,C标准遵循C,例如,C 11遵循C99,按照C 11 1.1 / 2.具体而言,C 11 18.4.1 Header< cstdint>概要/ 2状态：

所以,让我们先解决你的第@L_673_2@争论,你说：

C标准可以这么说,在c99 7.18.1.3最快的最小宽度整数类型(我的斜体)：

因此,对于所有可能的用途,类型不是最快的,这确实是正确的,但这似乎不是作者在定义这些方面时所考虑的.

引入固定宽度类型(在我看来)是为了解决所有开发人员在各种实现中具有不同int宽度的问题.

类似地,一旦开发人员知道他们想要的值范围,快速最小宽度类型就可以让他们以最大可能的速度对这些值进行算术运算.

在最后一段中涵盖您的三个具体问题(下面以粗体@L_674_10@)：

(1)标准是否允许这样的编译时间决议？

我不相信. C标准的相关部分有这一小段文字：

这似乎表明它必须是实现提供的typedef,并且由于没有“变量”typedef,因此必须修复它.

可能存在摆动空间,因为根据某些环境考虑因素可能提供不同的typedef,但实际实现这一点的难度似乎非常高(请参阅下面我对第三个问题的回答).

其中最主要的是这些适应性类型,如果它们具有外部联系,则需要在链接在一起时在所有编译的翻译单元之间达成一致.@L_673_2@单元具有16位类型而另@L_673_2@单元具有32位类型将导致各种问题.

(2)如果是,为什么不在今天实施？

我正在推动“不”作为对你的第@L_673_2@问题的回答所以我不打算推​​测这个,除了通过引用你对下面第三个问题的答案(它可能没有实施,因为它非常难,有可疑的好处).

(3)如果不是,为什么不在标准中？

标准是实现者和用户之间的契约,描述了实现者将提供的内容.通常情况下,标准委员会往往比前者(他们并不热衷于为自己做太多的额外工作)比后者更多地填充.

例如,我希望在C中拥有所有你自己的C数据结构,但这会导致标准版本相隔几十年而不是几年:-)