用int_fastN_t代替intN_t好不好

Question

我刚读到这个 ​​link: The difference of int8_t, int_least8_t and int_fast8_t? 现在我知道 int8_t 恰好是 8 位，而 int_fast8_t 是最快的至少有 8 位的 int 类型位。

我是一名开发人员，在 Linux 上使用 c++11 开发后端进程。大多数时候我不需要担心进程的大小。但我需要始终关心项目中整数的大小。比如我想用一个int来存储用户的ID或者存储一个毫秒级的时间点，我不能简单地使用int因为它可能会导致溢出，我必须使用int32_t或者int64_t.

所以我在想是否可以到处使用 int_fast8_t 并停止使用 int8_t（与 int_fast32_t、int_fast64_t、uint_fast8_t 等相同).

好吧，使用 int_fastN_t 可能不会有任何改变，因为我的程序总是部署在 X86 或 Arm64 上。但是我还是想知道如果把intN_t全部改成int_fastN_t有什么弊端吗？如果没有任何缺点，我想我会开始使用 int_fastN_t 而停止使用 intN_t.

Answer 1

So I'm thinking if it's good to use int_fast8_t everywhere

没有。不好用到处.

I still want to know if there is any drawback if I change all of intN_t into int_fastN_t

主要缺点是整数的大小不会正好是 N 位。在某些用例中，这是至关重要的。

另一个潜在的缺点是它可能更慢。是的，“快速”类型的别名可能会更慢。别名不是魔法；效率取决于用例。

如果满足以下条件，则可以使用“fast”别名：

• 确切大小无关紧要，重要的是最小值。
• 您可以选择稍后更改类型（无需向后兼容）。
• 您没有时间衡量哪种类型实际上最快（这通常是合理的）。

您没有提出使用固定宽度整数的缺点。但为了平衡起见，我会提到：不能保证在所有系统上都提供它们。当然，它们在其他一些用例中可能会更慢（考虑到命名，这可能不那么令人惊讶）。