使用非固定整数（int，long）而不是固定大小（int64_t，int32_t）是否有任何优势？

Question

也许表现？我觉得使用非固定整数只会使程序更复杂，并且在移植到另一个架构时容易失败。

Answer 1

提供了{p> std::intN_t only if the implementation can directly support them。因此移植使用它们的代码可能会失败。

我希望std::intfastN_t用于一般用途，因为它们的限制较少，应该与int一样快或更快。

此外，大多数C ++代码在任何地方都使用int，因此在将std::int32_t传递给接受int的函数时，您可能会遇到促销上的怪异，尤其是sizeof(int)只是{{1}} 16位。

Answer 2

许多API接受或返回非固定类型的值。例如，文件描述符的类型为int，文件偏移量或大小的类型为off_t，strtol()返回long。盲目地将这些值从固定大小类型转换为固定大小类型可能会导致某些机器出现溢出。

Answer 3

保证宽度类型（intN_t）只是适用于“标准”整数类型的typedef。如果平台没有合适的类型（例如，它使用36位整数），那么它不能也不能提供保证宽度的typedef。 这意味着表现几乎不可能是一个论点。

最大可移植性的一般准则（在这方面）是默认情况下使用“标准”整数类型，只有在算法需要精确位数时才使用保证宽度类型。 “标准”整数类型应该假设只有相关标准保证的宽度（如果你只看C ++标准，那就是：8位char，16位{{1} }，32位int，如果您的编译器支持它，则为64位long）。

Answer 4

如果您的数据大小类型对其功能至关重要，那么您应该使用具有已定义大小的类型。但是，例如，一段代码完全在[你可以合理地期望] int范围内（例如1 ... 1000循环计数器），没有理由使用int_32t只是因为你想定义你的变量。它可以很好地使用16,32,64,36,18或49位整数，都是一样的。因此，让编译器选择最佳的大小。

编译器有可能为固定大小的整数生成更糟糕的代码，这些整数不是架构的“最佳选择”。

显然，通过网络或文件呈现的任何数据都需要具有固定大小。同样，如果您的接口需要跨接口边界的二进制兼容性，那么使用定义的大小类型对于避免出现问题的大小非常有用。