情况：
我有一个用 C 语言编写的应用程序，它是资源密集型的，并且设计为可移植的。我想让编译器为架构选择最快的 int 大小，前提是它至少为 32 位。
是否可以选择“至少”32 位的大小，或者编译器会自动优化这些东西吗？
【问题讨论】：
long 的用途。
stdint.h typedefs，比如int_least32_t
标签： c++ c optimization
标准标头stdint.h 提供int_leastN_t 和uint_leastN_t 类型，其中N 是8、16、32 和64（可能还有其他，但这些不是必需的）。这些是 C99 的标准。
它还提供“快速”替代方案，即int_fastN_t 和uint_fastN_t，具有相同的N 值。
因此，在您的情况下，您可以使用int_least32_t 或int_fast32_t。
【讨论】：
int_fast32_t 是 OP 在这里需要的。 int_least32_t 不是 32 位以上的最快整数类型，只是最小的。
int_fast32_t 在 x86_64 这样的重要架构上被错误定义，它实际上是 慢得多 类型（64 位而不是 32 位）：对于 +/ -/* 两者的速度相同，但对于 / 来说速度要慢得多，当然加载/存储速度也更慢，因为您使用了两倍的缓存线和两倍的内存带宽。所以我真的很犹豫要不要使用它。我不知道 any 具有 32 位 int 的拱门，它不是处理“至少 32 位”整数的最快类型。
short 不应该同样如此吗？即短裤的划分不应该更快（假设它们实际上更小并且C没有自动将它们提升为int）？
-march 或其他什么来更改类型，因为这会破坏 ABI。
这个问题也被标记为 C++，所以这里是像我这样的模板元编程爱好者的解决方案。
list。filter 元函数。head 元函数，用于获取类型列表的第一个元素。此解决方案自动执行已接受的解决方案（即“转到stdint.h 并选择最适合您的解决方案”）。那项工作可以由编译器完成，不是吗？
首先列出在<cstdint> 声明的所有特定于平台的最快整数类型：
using integer_types = list<std::int_fast8_t,std::int_fast16_t,
std::int_fast32_t,std::int_fast64_t>;
请注意，列表是按整数大小递增排序的。
现在定义一个过滤谓词。在我们的例子中，大小应该小于用户指定的大小（命名为SIZE）：
template<typename T>
using f = std::integral_constant<bool,sizeof(T)*CHAR_BITS <= SIZE>;
然后过滤整数类型列表，得到结果的第一个元素：
using best_integer_t = head<filter<f,integer_types>>;
template<std::size_t SIZE>
struct fastest_integer_impl
{
//Guard for the case the user specified less than one byte size:
static constexpr const std::size_t size = SIZE >= CHAR_BITS ? size : CHAR_BITS;
using integer_types = list<std::int_fast8_t,std::int_fast16_t,
std::int_fast32_t,std::int_fast64_t>;
template<typename T>
using f = std::integral_constant<bool,sizeof(T)*CHAR_BITS <= size>;
using type = head<filter<f,integer_types>>;
};
template<std::size_t SIZE>
using fastest_integer = typename fastest_integer_impl<SIZE>::type;
【讨论】：
fastest_integer<4> 给出与std::int_fast32_t 相同的值吗？这比直接使用std::int_fast32_t 有什么好处？
正如其他人所指出的，标准包含文件定义了int_fast32_t、int_least32_t、uint_fast32_t、uint_least32_t，它们的行为可能会如您所愿，但使用此类类型时需要格外小心。由于整数提升规则，C 代码无法避免使用类型int 和unsigned int。此外，整数文字可能并不总是属于人们所期望的类型。例如，int_fast32_T 与文字 0xABCD1234 或 12345u 之间的比较可以作为有符号或无符号执行，具体取决于 int 是 16 位、32 位还是 64 位。同样，如果 n 是 32 位或更大，n &= ~0x8000; 的含义在 16 位机器上与在更大的机器上会有所不同。
C 标准从未专门设计用于方便编写关心整数大小的代码，但仍可在不同大小的硬件上兼容工作。像int_fast32_t 这样的类型可以轻松编写看起来应该是可移植的代码，但可能会鼓励人们对隐藏在语言中的所有讨厌的小陷阱感到自满。
【讨论】：
最快 => 使用编译指示包与架构对齐。如果没有这个，如果内存没有对齐，则需要不止一次的内存访问。
min 32 => 使用 int 说明符 - 足够了。据我所知，这确保了 linux 中所有架构的 32 位。
【讨论】：
pragma pack 将导致错位，因为它会阻止编译器插入保持数据对齐所需的填充。