c++ - 在 C 系列语言中使用明确大小的类型的缺点或权衡

Question

我正在开发几个需要跨多个桌面和移动平台移植的 C 和 C++ 项目。我知道在我向磁盘读写数据时使用明确大小的类型 u32_t i64_t 等很重要。

使用所有整数类型的显式大小类型来确保一致执行是否是个好主意？我听说显式大小的类型会影响性能，因为处理器针对它们预期的 int 类型等进行了优化。我还读到一个好的策略是在内部为类数据成员使用显式大小的类型，而不是在接口(interface)中。

关于数据成员和接口(interface)上明确大小的类型，是否有任何最佳实践？ (我假设在这些情况下 C 或 C++ 之间不会有很大的区别，但如果有的话请告诉我)

Answer 1

基本“int”类型的好处在于，对于您当前正在编译的任何平台，它几乎总是最快的整数类型。

另一方面，使用 int32_t(而不仅仅是 int)的优点是您的代码可以指望 int32_t 始终是 32 位宽，无论它是在什么平台上编译的，这意味着您可以安全地与使用 int 相比，对值的行为做出更多假设。对于固定大小的类型，如果您的代码完全可以在新平台 Y 上编译，那么它的行为更有可能与在旧平台 X 上完全相同。

int32_t 的(理论上的)缺点是新平台 X 可能不支持 32 位整数(在这种情况下，您的代码根本无法在该平台上编译)，或者它可能支持它们但处理它们的速度比它慢将处理普通的旧整数。

上面的例子有点做作，因为几乎所有现代硬件都全速处理 32 位整数，但确实存在(并且确实存在)处理 int64_ts 比处理 int 慢的平台，因为 (a) CPU 有32 位寄存器，因此必须将每个操作分成多个步骤，当然 (b) 64 位整数将占用 32 位整数两倍的内存，这会给缓存带来额外的压力。

但是:请记住，对于人们编写的 99% 的软件，这个问题不会对性能产生任何可观察到的影响，仅仅是因为如今 99% 的软件都不受 CPU 限制，并且即使对于这样的代码，整数宽度也不太可能成为主要的性能问题。所以真正归结为，您希望您的整数数学如何表现？

• 如果您希望编译器保证您的整数值始终占用 32 位 RAM，并且始终以 2^31(或 2^32 对于无符号)，无论您在哪个平台上进行编译，请使用 int32_t(等)。

• 如果您真的不关心包装行为(因为您知道您的整数永远不会包装，因为它们存储的数据的性质)，并且您想让代码更具可移植性对于奇怪/不寻常的编译目标，并且至少在理论上更快(尽管在现实生活中可能不是)，那么您可以坚持使用普通的旧 short/int/long。

我个人默认使用固定大小的类型(int32_t 等)，除非有非常明确的理由不这样做，因为我想尽量减少跨平台的变体行为。例如，这段代码:

for (uint32_t i=0; i<4000000000; i++) foo();

... 将始终恰好调用 foo() 4000000000 次，而这段代码:

for (unsigned int i=0; i<4000000000; i++) foo();

可能调用 foo() 4000000000 次，或者它可能进入无限循环，具体取决于 (sizeof(int)>=4) 与否。当然，可以手动验证第二个代码段不会在任何给定平台上执行此操作，但考虑到两种样式之间的性能差异可能为零，我更喜欢第一种方法，因为预测其行为是轻而易举的事。我认为 char/short/int/long 方法在 C 的早期更有用，当时计算机体系结构更加多样化，而且 CPU 足够慢，实现完整的 native 性能比安全编码更重要。