在32位机器上使用__int8_t对一些小值进行无用的优化工作？

这不仅可以是无用的优化,而且可能导致整数未对齐(即,整数未与4字节或8字节边界对齐,具体取决于体系结构),这实际上可能会降低性能.为了解决这个问题,大多数编译器尝试在大多数体系结构上对齐整数,因此您可能根本不会保存任何空间,因为编译器添加了填充(例如,对于基于堆栈的变量和结构成员)以正确对齐较大的变量或结构成员跟随你的8位整数.既然你的问题看起来像关于函数中的局部变量并且假设只有一个这样的变量并且函数不是递归的,那么优化很可能是不必要的,你应该只使用平台本机整数大小(即,int).

如果你有很多特定类型的实例并希望通过使用8位字段而不是64位字段来表示结构中的小整数,那么你提到的优化是值得的.如果这是您的意图,请确保为您的平台使用正确的pragma和/或编译器开关,以便将结构正确打包到最小的大小.使用较小整数大小的另一个实例可以派上用场,当涉及阵列,尤其是大型阵列时.最后,请记住,指定类型中的位数是不可移植的,因为其名称中的前导双下划线表示.

我有可能提到这一点,因为它似乎只与您的问题切线相关,但你可以在结构中甚至小于8位整数,甚至更小的值范围而不是0-255.在这种情况下,bit fields成为一种选择 – 微优化的缩影.除非您实际测量了时域和空间域中的性能,否则不要使用位字段,并且确保可以节省大量成本.为了进一步劝阻你,我提出了在下一段中使用它们的一些缺陷.

比特字段通过强制您手动命令结构成员将数据打包到尽可能少的字节来增加开发过程的复杂性 – 这项任务不仅是艰巨的,而且通常会导致完全不直观的结构成员变量排序.成员变量的更改,添加和删除通常倾向于级联到跟随它们的成员,从而导致维护问题.为了解决这个问题,开发人员经常将填充和对齐位粘贴到结构中,这使得除了代码的原始开发人员以外的所有进程更加复杂.评论这样的代码不再是一种精确的,而且往往成为必需品.还有一个问题是开发人员忘记了他们正在处理代码中的一个字段并将其视为具有其基础类型的整个域,从而导致无法结束静默,有时难以在/溢出下调试.

根据上述指南,对您的应用程序进行概要分析,以了解刚才讨论的优化是否对您的特定编译器和平台有意义.