压倒性的建议似乎是在C中更喜欢int s，除非空间很重要（http://c-faq.com/decl/inttypes.html）。
倾向于使用最短的类型会不会更有意义吗？
较短的类型在大型集合中具有明显的优势 - 使用较短的类型，集合将占用更少的空间。
在数值函数中，int具有优势，因为CPU应该更快地使用它们，但是当优化器在int交换时不是这样做的。我在堆栈上声明short，然后我继续计算？
我已经尝试编译了几个数值函数，一次是短路，然后是整数，我在-O3得到了相同的输出汇编（短路是2字节，而我的架构中的整数是4）所以看起来似乎int建议不再有效，特别是考虑到空间节省的可能性，考虑到CPU /内存性能差距的扩大，这应该比以往更重要。 （我认为在数字和大型集合中使用数据结构是相当普遍的。）
我有什么理由不倾向于默认为最短的类型吗？
答案 0 :(得分：3)
您应该坚持标准int，因为它是机器最容易使用的尺寸。其他尺寸需要额外的说明或特殊说明，这些说明需要更多空间。
你说你得到的是与-O3相同的输出程序集，但我会仔细检查，例如我会在汇编语言输出文件之间运行 diff 。
如果您有一个大数的整数值，这样数据空间差异超出了程序大小差异，那么请考虑更短的值。 即便如此，只关心存储大小实际上是一个问题。 通常不是。
答案 1 :(得分：0)
我同意迈克关于坚持原生尺寸的评论。我从硬件角度理解你的问题（它应该是总线上启用哪些字节的问题）。
如果您有32位总线但决定使用16位或8位整数，则可能会对处理器造成打包/解包成本。我使用的一些较旧的RISC处理器只想一次获取32位。因此，如果你想更新一个字节，它必须首先读取整个32位，然后它需要屏蔽掉感兴趣的字节。
无论如何，请使用目标编译器和优化设置进行测试。如果您确实看到32与16或8位整数的差异，请查看您的编译器是否可以为您提供一个列表，并且可以让您了解编译器如何处理short（er）整数。