使用所有整数类型的显式大小的类型来确保一致执行是一个好主意吗？我听说明确大小的类型可能会产生性能影响,因为处理器是针对其预期的int类型进行了优化的.我也读过一个好的策略是在内部为类数据成员使用显式大小的类型,而不是在接口中使用.@H_404_3@
有关数据成员和接口上显式大小类型的最佳做法？ (我假设C或C在这些情况下不会有很大的区别,但是让我知道是否有)@H_404_3@
解决方法
另一方面,使用int32_t(而不仅仅是int)的优点是,无论你编译什么平台,你的代码都可以依赖int32_t总是32位,这意味着你可以安全地做出更多的假设关于值的行为比你可以用int.对于固定大小的类型,如果您的代码在新平台Y上完全编译,那么它更可能与旧平台X上的行为完全相同.@H_404_3@
int32_t的(理论)缺点是,新的平台X可能不支持32位整数(在这种情况下,您的代码根本不会在该平台上进行编译),或者它可能支持它们,但是处理它们比处理简单旧的ints@H_404_3@
上面的例子是有点设计的,因为几乎所有的现代硬件都以全速处理32位整数,但是存在(和做)存在的操作int64_ts比操纵int更慢的平台,因为(a)cpu有32位寄存器,因此必须将每个操作分成多个步骤,当然(b)一个64位整数将占用32位整数的两倍的内存,这可能对缓存造成额外的压力.@H_404_3@
但是,请记住,对于99％的软件人员来说,这个问题不会对性能产生任何可观察的影响,因为这些日子里99％的软件没有cpu限制,甚至是代码就是,整数宽度不太可能是性能上的一个大问题.那么真正归结的是,你想要你的整数数学怎么样？@H_404_3@
>如果您希望编译器保证您的整数值总是占用32位RAM,并且将始终以2 ^ 31(或2 ^ 32为无符号)“环绕”,无论您正在编译什么平台,去与int32_t(等).
>如果你真的不在乎包装行为(因为你知道你的整数永远不会包装,因为他们存储的数据的性质),并且你想使代码更容易的奇怪/不寻常的编译目标,至少在理论上更快(尽管可能不在现实生活中),那么你可以坚持使用纯旧的短/长/长.@H_404_3@
我个人使用固定大小的类型(int32_t,etc)默认情况下,除非有一个非常明确的原因不要,因为我想最小化跨平台的变体行为的数量.例如,这段代码：@H_404_3@
for (uint32_t i=0; i<4000000000; i++) foo();
…将永远调用foo()正好4000000000次,而这个代码：@H_404_3@
for (unsigned int i=0; i<4000000000; i++) foo();
可能会调用foo()4000000000次,否则可能会进入无限循环,具体取决于是否(sizeof(int)> = 4).当然可以手动验证第二个代码片段在任何给定的平台上都不会这样做,但考虑到两种样式之间的可能零性能差异,我更喜欢第一种方法,因为预测其行为是一种无效的,闻风而动.我认为,在C的早期,char / short / int / long方法更有用,当计算机体系结构变化多变时,cpu运行速度很慢,实现完全本机性能比安全编码更重要.@H_404_3@
