C标准类型的实现将(u)int_fastX类型定义为其内置类型之一.这需要研究哪种类型最快,但每种情况都不可能有一种最快的类型.
在编译时通过选择实际使用的最佳类型来解决此类问题,是否会提高性能？编译器将分析_fast变量的使用,然后选择最佳类型.发挥作用的因素可能是对齐以及与变量一起使用的操作类型.
这将有效地使这些类型成为语言特征.
当编译器突然决定为这样的变量选择另一个宽度时,这可能会引入错误.但是在这种用例中不应该使用_fast类型,其行为取决于宽度.
标准是否允许这样的编译时间解析？
如果是的话,为什么不在今天实施呢？
如果不是,为什么它不符合标准？
最佳答案 不,标准不允许这样做.请记住,对于此特定区域,C标准遵循C,例如,C 11遵循C99,按照C 11 1.1 / 2.具体而言,C 11 18.4.1 Header< cstdint>概要/ 2状态：
The header defines all functions, types, and macros the same as 7.18 in the C standard.
所以,让我们先解决你的第一个争论,你说：
Implementations of the C++ standard typedef the (u)int_fastX types as one of their built in types. This requires research in which type is the fastest, but there cannot be one fastest type for every case.
C标准可以这么说,在c99 7.18.1.3最快的最小宽度整数类型(我的斜体)：
Each of the following types designates an integer type that is usually fastest to operate with among all integer types that have at least the specified width.
The designated type is not guaranteed to be fastest for all purposes; if the implementation has no clear grounds for choosing one type over another, it will simply pick some integer type satisfying the signedness and width requirements.
因此,对于所有可能的用途,类型不是最快的,这确实是正确的,但这似乎不是作者在定义这些方面时所考虑的.
引入固定宽度类型(在我看来)是为了解决所有开发人员在各种实现中具有不同int宽度的问题.
类似地,一旦开发人员知道他们想要的值范围,快速最小宽度类型就可以让他们以最大可能的速度对这些值进行算术运算.
在最后一段中涵盖您的三个具体问题(下面以粗体显示)：
(1)标准是否允许这样的编译时间决议？
我不相信. C标准的相关部分有这一小段文字：
For each type described herein that the implementation provides,
<stdint.h>shall declare thattypedefname and define the associated macros.
这似乎表明它必须是实现提供的typedef,并且由于没有“变量”typedef,因此必须修复它.
可能存在摆动空间,因为根据某些环境考虑因素可能提供不同的typedef,但实际实现这一点的难度似乎非常高(请参阅下面我对第三个问题的回答).
其中最主要的是这些适应性类型,如果它们具有外部联系,则需要在链接在一起时在所有编译的翻译单元之间达成一致.一个单元具有16位类型而另一个单元具有32位类型将导致各种问题.
(2)如果是,为什么不在今天实施？
我正在推动“不”作为对你的第一个问题的回答所以我不打算推测这个,除了通过引用你对下面第三个问题的答案(它可能没有实施,因为它非常难,有可疑的好处).
(3)如果不是,为什么不在标准中？
标准是实现者和用户之间的契约,描述了实现者将提供的内容.通常情况下,标准委员会往往比前者(他们并不热衷于为自己做太多的额外工作)比后者更多地填充.
例如,我希望在C中拥有所有你自己的C数据结构,但这会导致标准版本相隔几十年而不是几年:-)
