RLH*_*RLH 5 c xcode cocoa cocoa-touch objective-c
在浏览iPhone的示例代码应用程序时,我发现了一对有效具有相同签名定义的发送/接收方法,但与其中一个变量关联的值类型除外.
从标题内:
- (void)receivedData: (unsigned char *)data length:(NSUInteger)len;
- (void)sendData: (uint8_t*) data length:(NSUInteger) len;
Run Code Online (Sandbox Code Playgroud)
这些方法用作发送/接收进程的包装器,它有效地传递指向byte正在写入数据流和从数据流写入的数据数组的指针.我发现这些方法签名有点好奇,因为我是Cocoa/Cocoa Touch dev的新手,所以我决定查看该uint8_t类型的定义.我发现它uint8_t被定义为unsigned char内部stdint.h,因此,data这些方法的变量完全相同.至少,stdint.h在XCode 4.2中链接的情况就是如此.
然而,对uint8_t类型进行了一些进一步的研究,我发现了关于与使用的问题.共识似乎是这两种值类型完全相同但是对于C标准库的一些实现,它们可能是不同的.因此,人们不应相信在生成可移植代码时它们将是相同类型的数据.uint8_tunsigned char
话虽如此,从Apple/Objective-C编程环境中假设是否可以安全地uint8_t使用,unsigned char或者我应该遵循上述问题中给出的相同建议吗?
这可能看起来像一个挑剔的问题,但是因为我可能正在集成库,这种类型的编码错误行为似乎在个人代码库中有点普遍,可以在多个Apple环境中使用(相当长一段时间)来了),我想进一步评论.
忽略可移植性问题(正如您含蓄地要求我们做的那样),在 Mac OS X 及其衍生产品(例如 iOS)下, char 似乎极不可能是八位值以外的任何值。我认为您可以放心地假设 unsigned char 和 uint8_t 将永远相同。
也就是说,我认为作为程序员的一种文档形式,当您处理一个用于保存二进制数据字节而不是字符的值时,使用“byte”或“uint8_t”似乎更明智或者一些类似的方法向未来的读者表明函数的目的是将值视为字节而不是字符本身。
| 归档时间: |
|
| 查看次数: |
1444 次 |
| 最近记录: |