c++ - 为什么首选 uint32_t 而不是 uint_fast32_t？

Question

似乎 uint32_t 比 uint_fast32_t 更普遍(我知道这是轶事证据)。不过，这对我来说似乎违反直觉。

几乎总是当我看到一个实现使用 uint32_t 时，它真正想要的只是一个整数，它可以容纳高达 4,294,967,295 的值(通常是在 65,535 和 4,294,967,295 之间的一个低得多的范围)。

然后使用 uint32_t 似乎很奇怪，因为不需要 '正好 32 位' 保证，并且 '最快可用 >= 32 位' uint_fast32_t 的保证似乎是完全正确的想法。而且，虽然它通常被实现，但实际上并不能保证 uint32_t 存在。

那么，为什么首选 uint32_t 呢？它只是更广为人知还是有技术优势？

Answer 1

uint32_t 保证在任何支持它的平台上具有几乎相同的属性。¹

uint_fast32_t 与之相比，它在不同系统上的表现几乎没有保证。

如果您切换到 uint_fast32_t 具有不同大小的平台，则必须重新测试和验证所有使用 uint_fast32_t 的代码。所有的稳定性假设都将不复存在。整个系统将以不同的方式工作。

在编写代码时，您甚至可能无法访问到不是 32 位大小的 uint_fast32_t 系统。

uint32_t 不会有不同的工作方式(见脚注)。

正确性比速度更重要。因此，过早的正确性比过早的优化更好。

如果我正在为 uint_fast32_t 为 64 位或更多位的系统编写代码，我可能会针对这两种情况测试我的代码并使用它。除非需要和机会，否则这样做是一个糟糕的计划。

最后，uint_fast32_t 当您存储它任何时间长度或实例数量时可能会比 uint32 慢，这仅仅是由于缓存大小问题和内存带宽问题。今天的计算机更多地受内存限制而不是 CPU 限制，并且 uint_fast32_t 可能会更快，但考虑到内存开销后则不然。

---

¹ 正如@chux 在评论中指出的那样，如果 unsigned 大于 uint32_t，则在 uint32_t 上进行算术运算> 经历通常的整数提升，如果没有，它保持为 uint32_t。这可能会导致错误。没有什么是完美的。