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