过去几个月我一直在学习为Mac编程（我有其他语言经验）。显然，这意味着要学习Objective C语言，因此它就是它的基础。所以我引用了这个引用，这引用了一般的C / C ++语言，而不仅仅是Mac平台。
使用C和C ++更喜欢使用int over char和short。背后的主要原因 这就是C和C ++的表现 算术运算和参数 传递整数级别，如果你有 一个可以适合的整数值 字节，你仍然应该考虑使用 一个int来保存这个数字。如果你使用 一个char，编译器将首先 将值转换为整数， 然后执行操作 将结果转换回char。
所以我的问题是，这是Mac桌面和iPhone OS环境中的情况吗？我理解在谈论这些环境时，我们实际上是在讨论3-4种不同的架构（PPC，i386，Arm和A4 Arm变体），所以可能没有一个答案。
然而，一般原则认为，在现代32位/ 64位系统中，使用1-2字节变量与机器的自然4字节字不对齐，并不能提供我们预期的大部分效率。
例如，一个10万个字符的普通旧C-Array比相同的100,000个字符小4倍，但是如果在枚举期间读出每个索引涉及一个类型的转换/装箱/拆箱，我们会不会尽管节省了内存开销，但看到整体较低的“性能”？答案 0 :(得分：3)
与内存速度相比，处理器速度非常快。总是将内存中的值存储为chars或short（尽管为了避免移植问题，你应该使用int8_t和int16_t）。将使用更少的缓存，并且将减少内存访问。
答案 1 :(得分：2)
不能代表PPC / Arm / A4Arm，但是x86能够对数据进行操作，就好像它是8位，16位或32位（如果是64位模式的x86_64，则为64位），虽然我不确定是否编译器会利用这些指令。即使使用32位负载，编译器也可以使用掩码清除高16/24位的数据，这将相对较快。
可能，将更多数据放入缓存中的能力至少可以抵消速度差异......虽然唯一可以确定的方法是实际分析代码。
答案 2 :(得分：1)
当然需要使用小于目标机器的寄存器大小的数据结构。想象一下，你正在存储编码为UTF-8的文本数据，或者在内存中存储ASCII，其中每个字符大多像一个字节大小，你想将字符存储为64位数量吗？
您正在寻找的建议是警告，不要过度优化。 您必须平衡空间节省与您选择的计算性能。
我不会太担心它，今天的现代CPU很复杂，很难自己做出这种判断。选择明显的数据类型，让编译器担心其余的数据类型。
答案 3 :(得分：0)
x86架构的寻址模型是内存的基本单位是8位字节。
这是为了简化字符串和十进制算术的操作。
然后，为了获得有用的整数大小，指令集允许以1,2,4和（最近）8字节为单位使用它们。
答案 4 :(得分：0)
值得记住的是，大多数软件开发都是针对不同的处理器进行编写的，而不是我们这里的大多数人每天都在处理。
C和汇编程序是这些语言的通用语言。
2008年制造了大约100亿个CPU。每年生产的新CPU中约有98％是嵌入式的。