在C系列语言中使用显式大小的类型的缺点或权衡

Question

我正在开发几个需要在多个桌面和移动平台上移植的C和C++项目.我知道u32_t i64_在读取和写入磁盘数据时使用显式大小的类型等很重要.

使用所有整数类型的显式大小类型以确保一致执行是否是个好主意？我听说显式大小的类型可能会对性能产生影响,因为处理器针对其预期int类型进行了优化等.我还读到一个好的策略是在内部为类数据成员使用显式大小的类型,但不在接口中使用.

在数据成员和接口上是否有关于显式大小类型的最佳实践？(我假设在这些情况下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(等).

• 如果你真的不关心包装行为(因为你知道你的整数永远不会包装,因为它们存储的数据的性质),并且你想让代码更加便携,以用于奇怪/不寻常的编译目标,至少在理论上更快(虽然可能不在现实生活中),那么你可以坚持使用普通的旧/短/长/长.

我个人默认使用固定大小的类型(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足够慢以至于实现完全本机性能比安全编码更重要.

Answer 2

使用inttypes.h或stdint.h.它是ANSI-C,因此它将支持任何旨在符合ANSI标准的工具链.

此外,它仍然可以为您节省重新设计车轮的工作.

你唯一要做的就是

#include <inttypes.h>

uint32_t integer_32bits_nosign;

• 关于可移植性的另一个问题是:数据宽度是数据的最终性非常重要.您必须使用标准宏检查目标字节顺序:

  struct {
  #if defined( __BIG_ENDIAN__ ) || defined( _BIG_ENDIAN )
      // Data disposition for Big Endian   
  #else
      // Data disposition for Little Endian   
  #endif
  };
  

如果使用位字段,它会特别敏感.

编辑:

当然,<csdtint>如果您计划在仅使用C++的代码上使用它,您可以像其他人一样使用它.