C ++将long，short和all int转换为uint32_t，int32_t等等有帮助吗？

Question

我运行的是一个编码C ++的游戏服务器，还有一些ASM和C。我看到有人更新了我运行的同一台服务器，所有更新中的事实是所有int，unsigned，short以及其他所有内容都更改为int32_t，uint32_t，uint64_t和其他内容。

将所有这些改为上述的那些是否有任何好处？假设我将所有int更改为int32_t，将所有unsigned int更改为uint32_t，当然还有其他所有可能更改的内容。

我试图阅读并理解是否有任何好处，但我根本没有掌握它们的真正含义。所以是的，问题是：做我刚刚说的话有什么好处吗？

我使用的编译器是Orwell Dev-C ++

Answer 1

正常类型（如int和unsigned int）的大小可变，具体取决于您运行的平台。但是，int32_t和uint32_t在任何具有32位整数类型的平台上保证为32位。在没有的平台上，它不存在。 int的大小可能会有所不同，通常为32位或64位长。相同的规则适用于其他类型，例如int64_t是64位。

要知道网络编程中需要数据类型的大小，因为网络数据包是在具有不同默认整数大小的不同平台之间发送的，而存储在数据包中的数据大小（如地址和端口号）是总是一样。 IPv4地址总是32位长，并且应该使用保证为此大小的数据类型来存储它。

在大多数只存储数字的程序中，您应该使用普通类型。这些在当前平台上的效率最高。

Answer 2

uint32_t和int32_t通过固定大小和符号为数据类型的处理添加更多控制权 - 恕我直言，您在程序中的可预测性越高，就越好。您还可以在typename上看到它是否是无符号的，这可能并不总是不言自明的

使用明确定义的大小，在进行可移植代码时也会受到更多保护。

Answer 3

实际上，默认的int和long是如此模糊和编译器/平台依赖，我试图避免它们。使用int和long：

• 如果您需要知道结构的大小，您需要知道int和long，每个体系结构，每个操作系统，每个编译器的字节数。这是浪费宝贵的大脑。
• 如果您需要向某人解释在该哈希表中发生冲突的可能性，您会说“这取决于int的大小，这取决于您的架构”，或者您更愿意说，1.0e-5 ？换句话说，int和long“取消定义”程序的属性。
• 如果你使用int，并且编译器发誓那是64位，那么将它优化为32或16的可能性是最小的。所以你最终会使用更多的内存，如果你想要的只是代表一个短符号的空间......而不是我知道许多字符串有2 ^ 32个字符。

对于更多信息类型，如uint32_t或uint_least32_t，您的编译器可能会做出更好的假设并使用64位，如果它认为这会带来更好的性能。我肯定不知道。但是你作为人类有更好的机会去理解你的程序运作良好的价值范围。

此外，所有二进制协议都可能需要指定整数的大小和字节顺序。

Answer 4

在某些情况下，例如结构字段，我对int32_t没问题，但是 将您所有的int写成int32_t，将unsigned写成uint32_t（出于可移植性？）的做法被过度使用；我认为，实际上，您不会从此获得任何实际的可移植性好处，并且存在一些重大缺点。

• 您正在编写的代码很可能只会在int是32位的计算机上编译。如果要将其移植到具有16位int的计算机上，则通常遇到的问题比毯子typedef所能解决的要大得多。
• 如果您确实要迁移到16位计算机上，则可能无论如何都要将大量的本地int32_t更改为int，因为它们中的大多数是计数和索引， 16位计算机的大多数内容不能超过32K，但是人们只是出于习惯而写了它们，如果您将它们保留为int32_t，则代码将是庞大而缓慢的。
• int是将来某个时候的64位吗？由于多种原因，它们不会发生，其中大多数只是实用的事情。
• 在某些奇怪的机器上，int例如24位。非常不寻常，但是同样，您遇到的问题比typedef所解决的要大，如果移植到这样的野兽，您要做的第一件事可能就是将所有int32_t更改为{ {1}}。

不能解决可移植性问题的原因很多。有什么缺点？

• 某些库函数具有int参数，例如frexp。您需要提供一个int变量的地址，否则将无法移植，即使int为32位，int32_t可能也可能不是int（请参见下文）。我见过人们写int *只是为了使他们可以写frexp( val, (int*)&myvar);而不是int32_t myvar;，这很糟糕，并且如果int32_t与int的大小不同，则会产生编译器无法检测到的错误。

• 与之类似，int myvar;需要一个int，而不是某种恰好与int大小相同但可能确实很长的typedef，并且如果int32_t为printf( "%d", intvar);，则gcc / clang会对此发出警告

• 在许多平台上，long很长（32位长），尽管int32_t也是32位，但这很不幸（我认为可以追溯到Microsoft需要在16/32/64上重击，并确定long应该永远是32位，反之亦然）。

• 在跨平台移植代码时，不确定int32_t是int还是long会导致c ++重载问题。