定义一个字节的方法很多

时间:2012-06-08 09:11:37

标签: ios objective-c byte typedef

我在objective-c中使用哪一个(特别是在iOS上)会有所不同吗?我假设它来自继承自C及其类型,以及继承iOS所基于的Mac OS类型,但我不知道应该使用哪一种:

unsigned char来自......好吧......编译器?

来自stdint.h的

uint8_t

来自MacTypes.h的

UInt8

来自MacTypes.h的

Byte

来自zconf.h的

Bytef

我知道各种defs是出于可移植性的原因,并且使用像unsigned char这样的文字并不是一个好的未来想法(大小可能会改变,事情最终会像Windows API一样)。我想要一些关于如何发现最适合我用途的建议。如果我只是愚蠢的话,还是好好的抨击......

编辑:仅仅是为了获取更多信息,如果我想要始终为1字节的东西,我应该使用uint8_t(似乎它不会随着这样的名字)?我想UInt8也不会改变,但我发现UInt32的定义因处理器是否为64位而有所不同。

进一步编辑:当我说字节时,我特别指的是我想要8位。我正在进行像素压缩操作(32位 - > 8位)以进行磁盘存储。

2 个答案:

答案 0 :(得分:11)

这完全无动于衷。无论你使用哪一种,它最有可能最终成为unsigned char。但是,如果您希望它看起来不错,我建议您使用uint8_t中的<stdint.h>

两者都不会随着架构而改变。根据C标准,char始终为1字节,如果在实现中,UInt8突然变为16位长,则从用户的角度来看是不可接受的。

(但是,char不需要是8位宽,只是如果类型的名称表明它是8位长,那么任何明智的实现确实会对它进行类型化处理顺便说一句,一个字节(char是)通常是一个8位单位,即一个八位字节。)

答案 1 :(得分:0)

与从C语言类型模型派生的每种编程语言一样,Objective C有一些等效选项来声明一个8位整数。

为什么我说同等的?因为OP正确陈述,很明显所有这些选项最终typedef - 编译为unsigned char内置编译器类型。现在这是正确的,让我们说实话,没有人会在将来将它们改为非8位整数。

所以,这里的实际问题是在选择8位整数的类型名称时优先考虑注意事项的顺序是什么?

代码可读性

由于基本上在每个具有C语言根的代码中,原始类型名称都是混乱。因此,可能最重要的因素是可读性。我的意思是明确且唯一可识别的意图是为大多数阅读代码的人选择此特定整数的特定类型。

让我们从平均Objective C程序员的角度来看看那些对C语言知之甚少的类型。

  • unsigned char - 这是什么???为什么char有意签名???
  • uint8_t - 好的,无符号8位整数
  • UInt8 - 嗯,与上面相同
  • Byte - 有符号或无符号8位整数
  • Bytef - 这是什么?字节浮动?那'f'是什么意思?

这里很明显,unsigned charBytef不是一个好的选择。

更进一步,您可以注意到Byte类型名称的另一个麻烦:您无法确定它是否代表signedunsigned整数,这对您来说非常重要重新尝试理解这个整数可以容纳的值的范围(-128 .. 127或0 .. 256)。这也不是为代码可读性添加点。

统一代码风格

我们现在留下了2个类型名称:uint8_tUInt8。如何在它们之间做出选择?

再一次,通过Objective C程序员的眼睛看着他们,他们正在使用NSIntegerNSUInteger这样的类型名称,当他看到UInt8时看起来很自然。 uint8_t看起来只是一个非常低级的令人生畏的东西。

结论

因此,我们最终选择了单一选项 - UInt8 。在位数,范围和外观习惯方面可以清楚地识别出来。所以这可能是最好的选择。