在现代编程中，真的有这样的东西吗？

Question

在过去的几个月里，我一直在学习为Mac编写程序(我有其他语言的经验)。显然，这意味着学习目标C语言，因此它所依赖的C越简单。因此，我无意中引用了这个引语，它一般指的是C/C++语言，而不仅仅是Mac平台。

使用C和C++的

更喜欢使用int而不是char和short。这背后的主要原因是C和C++在整数级别执行算术操作和参数传递，如果您有一个可以容纳一个字节的整数值，那么仍然应该考虑使用int来保存这个数字。如果使用char，编译器将首先将值转换为整数，执行操作，然后将结果转换为char。

所以我的问题是，在Mac和IPhone操作系统环境中是这样的吗？我理解在讨论这些环境时，我们实际上讨论的是3-4个不同的体系结构(PPC、i386、Arm和A4 Arm变体)，所以可能没有一个单一的答案。

然而，一般原理是否认为，在现代32位/ 64位系统中，使用与机器的自然4字节字不一致的1-2字节变量并不能提供我们所期望的很高的效率。

例如，一个普通的有100万个字符的C-Array比相同的10万个ints小4倍，但是如果在枚举过程中，读取每个索引涉及一个类型的强制/装箱/取消装箱，那么尽管节省了内存开销，我们会看到整体的“性能”更低吗？

Answer 1

与内存速度相比，处理器非常快。在内存中将值存储为字符或简短(虽然为了避免移植问题，您应该使用int8_t和int16_t)，这将是值得的。使用的缓存将更少，内存访问将更少。

Answer 2

不能代表PPC/Arm/A4Arm，但是x86有能力对数据进行操作，就好像它是8位、16位或32位(如果64位模式下的x86_64是64位)，尽管我不确定编译器是否会利用这些指令。即使在使用32位加载时，编译器也可以使用屏蔽来清除上16/24位的数据，这将是相对较快的。

很可能，将更多的数据放入缓存中的能力至少会抵消速度差异.不过，唯一确定的方法是对代码进行实际分析。

Answer 3

当然，需要使用小于目标机器的寄存器大小的数据结构。假设您正在将编码为UTF-8或ASCII的文本数据存储在内存中，其中每个字符的大小大多类似于一个字节，您想要将这些字符存储为64位量吗？

你正在寻求的建议是一个警告，不要过度优化。你必须平衡节省的空间和你选择的计算性能。

我不会太担心它，今天的现代CPU已经够复杂了，你自己很难做出这样的判断。选择明显的数据类型，让编译器担心其余的数据类型。