为什么固定宽度类型委托回原语？

Question

在Visual Studio 14中，stdint.h标题包含固定宽度整数类型的定义，但如果您实际查看定义，则只需将其委托回基元。定义如下：

typedef signed char        int8_t;
typedef short              int16_t;
typedef int                int32_t;
typedef long long          int64_t;
typedef unsigned char      uint8_t;
typedef unsigned short     uint16_t;
typedef unsigned int       uint32_t;
typedef unsigned long long uint64_t;

如果所有它只是回退到原语，那么有没有理由使用stdint.h？我也知道Visual Studio不只是在编译时替换这些定义，因为如果你试图将int8_t打印到控制台，你将获得一个Unicode字符而不是一个数字，因为它实际上只是一个{{1 }}

修改

因为人们指出他们在逻辑上没有别的定义，我认为我的问题需要重述。

为什么在C ++规范中声明它将具有固定长度8,16,32和64位的整数的头将这些整数定义为根据定义可以是编译器想要的任何大小的类型（对于在另一个问题signed char）中以别人的方式说出来了吗？

Answer 1

不同的平台以不同的方式定义基元。在一个平台上int可能是16位，而在另一个平台上它是32位。如果您严格依赖具有特定宽度的变量，则应使用stdint.h中的类型，这些类型将始终typedef正确显示在当前平台上的各自基元。

Answer 2

  

那么有没有理由使用stdint.h如果它只是回退到原语？

它还能做什么？

标头中定义的所有类型都可以追溯到内置类型。

此标题只为您提供方便的，标准定义的，保证一致的别名。

Answer 3

从原始问题和重述的问题中我都了解到，对于保证宽度整数（我说保证是因为并非stdint.h中的所有类型都不都是固定宽度）及其解决的实际问题存在误解。

C / C ++定义了诸如int，long int，long long int等原语。为简单起见，我们将重点放在最常见的int上。 C标准定义的int至少应为16位宽。不过，在定义int时，所有广泛使用的x86平台上的编译器实际上将为您提供32位宽的整数。发生这种情况是因为x86处理器可以直接从内存中获取32位宽的字段（字大小为32位x86 CPU），将其按原样提供给ALU以进行32位算术，然后将其存储回内存，而无需执行任何操作移位，填充等，这非常快。但是，并非每种编译器/架构组合都如此。如果您使用的是嵌入式设备（例如，非常小的MIPS处理器），则在定义int时，可能会从编译器获得16位宽的整数。 因此，相对于标准定义的最小宽度，编译器完全根据目标平台的硬件功能来指定基元的宽度。是的，在具有例如一个25位的ALU，您可能会得到一个25位的int。

为了使一段C / C ++代码可在许多不同的编译器/硬件组合之间移植，stdint.h提供了typedef，以保证您一定的宽度（或最小宽度）。因此，例如，当您要使用16位带符号整数（例如，用于节省内存或mod计数器）时，不必担心应该使用int还是short ，只需使用int16_t。 编译器的开发人员将为您提供一个正确构建的stdint.h，它将在所实现的实际基元中键入所请求的固定大小的整数。这意味着，在x86上，{{1} }可能会定义为int16_t，而在小型嵌入式设备上，您可能会得到short，所有这些映射都由编译器的开发人员维护。

Answer 4

在回答重述的问题时，并不是编译器选择在高57位存储生日。这是一个开发人员。编译器不能使用它想要的整数类型的任何位深度。它将使用编译器开发人员告诉它使用的任何位深度，开发人员将根据the requirements of the C++ standard选择这些位深度。一旦配置和编译了编译器，位深度就不会改变 ¹ 。在您更改编译器或编译器版本之前，将保证71位。

编写好的代码很难，编译器不会向你抛出变量。考虑可变位深度会发生什么。在周二的构建中输入很好并且会使喷气式客机崩溃，因为周三编译器执行了一些计算，并且决定它永远不会看到超过17位的任何内容。

¹ 我想你可以构建一个在运行时从配置文件中加载各种整数大小的编译器，但我怀疑它会使编写优化器变得非常复杂。