我最近发现存在标准的最快类型，主要是int_fast32_t和int_fast64_t。
我总是被告知，对于主流架构的正常使用，最好使用经典的 int ＆amp; long 应该始终符合处理器的默认读取容量，因此避免无用的数字转换。
在C99标准中，它在§7.18.1.3p2中说：
“typedef名称int_fastN_t指定宽度至少为N的最快有符号整数类型.typedef名称uint_fastN_t指定宽度至少为N的最快无符号整数类型。”
在§7.18.1.3p1中也引用了它：
“指定的类型不能保证最快用于所有目的;如果实现没有明确的理由选择一种类型而不是另一种类型，它将只选择一些满足签名和宽度要求的整数类型。”
我不清楚最快的真正含义。我不明白何时应该使用这种类型，何时不应该使用。
我在Google上搜索了一些内容，发现有些open source projects已将某些功能更改为它，但并非全部。他们并没有真正解释为什么他们改变了一部分，而只是他们的代码的一部分。
当int_fastXX_t 真的比经典更快时，你知道具体案例/用法是什么吗？
答案 0 :(得分：23)
在C99标准中，7.18.1.3最快的最小宽度整数类型。
（7.18.1.3p1）“以下每种类型都指定一个通常最快的整数类型225”，以便在所有至少具有指定宽度的整数类型中运行。“
225）“指定的类型不能保证最快用于所有目的;如果实现没有明确的理由选择一种类型而不是另一种类型，它将简单地选择一些满足签名和宽度要求的整数类型。”
和
（7.18.1.3p2）“typedef名称int_fastN_t指定宽度至少为N的最快有符号整数类型.typedef名称uint_fastN_t指定最快的无符号整数 宽度至少为N的类型。“
类型int_fastN_t和uint_fastN_t是完全宽度整数类型intN_t和uintN_t的对应项。实现保证它们至少占用N位，但如果可以使用更大的类型执行优化，则实现可以占用更多位;它只是保证它们至少占用N位。
例如，在32位计算机上，uint_fast16_t可以定义为unsigned int而不是unsigned short，因为使用机器字大小的类型会更有效。
它们存在的另一个原因是精确宽度整数类型在C中是可选的，但是最快的最小宽度整数类型和最小宽度整数类型（int_leastN_t和uint_leastN_t）是必需的。
答案 1 :(得分：2)
除了int32_t和int16_t甚至不存在的奇异硬件外，可能没有区别。
在这种情况下，您可以使用int_least16_t来获取可包含16位的最小类型。如果你想节省空间，这可能很重要。
另一方面，使用int_fast16_t可能会获得另一种类型，大于int_least16_t，但可能会更快＃34;典型的＆＃34;整数使用。实施必须考虑什么是更快和什么是典型的。对于某些特殊用途的硬件来说，这可能是显而易见的吗？
在大多数常见的机器上，这些16位类型都是short的typedef，你不必费心。
答案 2 :(得分：2)
Gnu libc defines {int，uint} _fast {16,32} _t在编译64位CPU时为64位，否则为32位。英特尔和AMD 64位x86 CPU上的64位整数运算速度比32位整数运算速度快。
答案 3 :(得分：1)
IMO他们毫无意义。
编译器不关心你所谓的类型，只关注它的大小以及适用于它的规则。因此，如果你的平台上的int，in32_t和int_fast32_t都是32位，那么它们几乎肯定都会执行相同的操作。
理论上说，语言的实现者应该根据硬件上的最快速度进行选择，但标准编写者从未明确指出最快的定义。再补充一点，平台维护者不愿意改变这些类型的定义（因为这将是一个ABI中断），并且定义最终在平台生命的开始时被任意挑选（或者从其他平台继承C库是从那里移出来，再也没有碰过。
如果您处于微优化级别，您认为可变大小可能会产生显着差异，那么使用您的处理器上的 代码对不同选项进行基准测试。否则不要担心。 “快速”类型不会添加任何有用的IMO。