使用和何时使用 int16_t,int32_t,int64_t 和分别 short int,int,long int,long答案

【问题标题】：Uses and when to use int16_t,int32_t,int64_t and respectively short int,int,long int,long使用和何时使用 int16_t,int32_t,int64_t 和分别 short int,int,long int,long
【发布时间】：2016-12-16 04:53:19
【问题描述】：

使用和何时使用int16_t、int32_t、int64_t 和分别为short、int、long。
C++中有太多该死的类型。对于整数，什么时候使用一个而不是另一个是正确的？

【问题讨论】：

坚持不该死的。
...以及无懈可击的零。
这样一个通用问题的上下文会很好。根据您需要支持的平台和生命周期，类型和类型处理的重量不同。如果您在嵌入式上锁定了步幅，那么您的需求与为 .NET 编写 OOP 内容的人的需求截然不同。 C++ 有这么多该死的类型，因为它支持这么多该死的截然不同的平台。

标签： c++ types integer

【解决方案1】：

当精度很重要时，使用定义明确的类型。如果不是，请使用不太确定的那些。使用更精确的永远不会错。使用灵活的有时会导致错误。

【讨论】：

当“更精确”不存在时使用它们是错误的。
警告购买者：平台特异性很重要。确保您使用所有目标都支持的类型，这取决于您的实现可能意味着使用在整个部署矩阵中表现良好的通用类型，或者微管理特定目标并自己提供一致性
@PeteBecker 作为最后一次使用“更精确”的努力，您可以为您正在工作的平台定义它们，当从一个有它们的平台移植到一个没有它们的平台时。

【解决方案2】：

当您实际需要精确宽度时，请使用精确宽度类型。例如，int32_t 保证为 32 位宽，没有填充位，并且具有二进制补码表示。如果您需要所有这些要求（可能是因为它们是由外部数据格式强加的），请使用int32_t。对于其他 [u]intN_t 类型也是如此。

如果您只需要至少 32 位的有符号整数类型，请使用int_least32_t 或int_fast32_t，具体取决于您是要优化大小还是速度。（它们很可能是同一类型。）

使用预定义类型short、int、long 等，如果它们足以满足您的目的并且您不想使用较长的名称。 short 和 int 都保证至少为 16 位，long 至少为 32 位，long long 至少为 64 位。 int 通常是系统架构建议的“自然”整数类型；您可以将其视为int_fast16_t，将long 视为int_fast32_t，但不能保证它们相同。

我没有给出使用内置与[u]int_leastN_t 和[u]int_fastN_t 类型的严格标准，因为坦率地说，没有这样的标准。如果选择不是由您使用的 API 或您组织的编码标准强加的，那么这实际上是个人品味的问题。尽量保持一致。

【讨论】：

【解决方案3】：

这是一个很好的问题，但很难回答。
一句话：取决于上下文：

我的经验法则：

我更喜欢代码性能（速度：时间少，复杂度低）
使用现有库时，我会遵循库编码风格（上下文）。
在团队中编码时，我会遵循团队编码风格（上下文）。
在编码新事物时，我会尽可能使用int16_t,int32_t,int64_t,..。

解释：

在某些情况下使用int（int 是系统字长）可以提高性能，但在其他情况下则不能。

我会使用uint64_t 而不是unsigned long long，因为它很简洁，但只要有可能。

所以 这取决于上下文

【讨论】：

【解决方案4】：

我发现它们的一个用途是当我为图像压缩器等数据打包时。使用这些精确指定字节数的类型可以省去很多麻烦，因为the C++ standard does not explicitly define the number of bytes in its types, only the MIN and MAX ranges.

【讨论】：