在NSInteger为iOS开发时,我应该何时使用vs int？我在Apple示例代码中看到,当将值作为参数传递给函数或从函数返回值时,它们使用NSInteger(或NSUInteger).
- (NSInteger)someFunc;...
- (void)someFuncWithInt:(NSInteger)value;...
但是在一个函数中,它们只是int用来跟踪一个值
for (int i; i < something; i++)
...
int something;
something += somethingElseThatsAnInt;
...
我读过(被告知),其NSInteger是引用在任何一个64位或32位环境中,为什么使用一个整数一个安全的方式int呢？
如何转换NSInteger为NSString数据类型？
我试过以下,其中月份为NSInteger:
NSString *inStr = [NSString stringWithFormat:@"%d", [month intValue]];
A NSInteger在32位平台上为32位,在64位平台上为64位.是否有一个NSLog总是匹配大小的说明符NSInteger？
建立
GCC_WARN_TYPECHECK_CALLS_TO_PRINTF 打开这让我有些悲伤:
#import <Foundation/Foundation.h>
int main (int argc, const char * argv[]) {
@autoreleasepool {
NSInteger i = 0;
NSLog(@"%d", i);
}
return 0;
}
对于32位代码,我需要说明%d符.但是,如果我使用说明%d符,我在编译64位时会收到警告,建议我使用%ld.
如果我使用%ld匹配64位大小,编译32位代码时,我会收到警告,建议我使用%d.
如何一次修复这两个警告？是否有我可以使用的说明符？
这也影响[NSString stringWithFormat:]和[[NSString alloc] initWithFormat:].
例如,将value消息传递给NSInteger类似的实例时
[a value] 它会导致EXC_BAD_ACCESS.
那么如何转换NSInteger为int？
如果相关,则只使用小于32的小数.
NSNumber和NSInteger有什么区别？我应该知道更多这样的原始人吗？浮筒有吗？
随着iOS版的64位版本,我们不能使用%d和%u再格式化NSInteger和NSUInteger.因为对于64位,这些是typedef'd long而unsigned long不是int和unsigned int.
因此,如果您尝试使用%d格式化NSInteger,Xcode将发出警告.Xcode对我们很好,并提供了这两种情况的替代品,它包括一个带有l前缀的格式说明符和一个长的类型转换.然后我们的代码基本上是这样的:
NSLog(@"%ld", (long)i);
NSLog(@"%lu", (unsigned long)u);
如果你问我,这是一个痛苦的眼睛.
几天前,Twitter上有人提到格式说明符%zd来格式化签名变量和%tu在32位和64位平台上格式化无符号变量.
NSLog(@"%zd", i);
NSLog(@"%tu", u);
这似乎有效.而且我更喜欢类型转换.
但老实说,我不知道为什么这些工作.现在两者对我来说基本上都是神奇的价值观.
我做了一些研究,并发现z前缀意味着以下格式说明符具有相同的大小size_t.但我完全不知道前缀是什么t意味着.所以我有两个问题:
究竟是什么%zd和%tu意味着什么呢？
是否可以安全使用%zd,%tu而不是苹果建议长期使用？
我知道类似的问题和Apples 64位过渡指南,它们都推荐这种%lu (unsigned long)方法.我要求替代铸造.
我正试着在iTunes U上从斯坦福大学开始学习iPhone课程,我对指针感到有些困惑.在第一次任务中,我尝试过做这样的事情
NSString *processName = [[NSProcessInfo processInfo] processName];
NSInteger *processID = [[NSProcessInfo processInfo] processIdentifier];
这产生了一个错误,在盲目地修复之后,我发现它是导致问题的NSInteger系列中的*.
所以我显然不明白发生了什么.我将解释我认为它是如何工作的,也许有人会善意地指出这个缺陷.
与Web开发不同,我现在需要担心内存,而不是Web开发.因此,当我创建一个变量时,它会在某处分配一些内存(我假设是RAM).我没有传递变量,而是将指针传递给周围的内存.并且通过在变量名前加上*来声明指针.
假设我是对的,让我感到困惑的是为什么我不需要为NSInteger做那个？
在如此声明枚举时,枚举常量的数据类型如何保证为NSUInteger而不是unsigned int:
enum {
NSNullCellType = 0,
NSTextCellType = 1,
NSImageCellType = 2
};
typedef NSUInteger NSCellType;
NSUInteger的typedef似乎没有以任何方式绑定到枚举声明.
我正在阅读Apple的64位Cocoa过渡指南,以获得有关枚举值的一些指导,我带来了一个问题.这是Enumeration Constants部分的一个(冗长的)引用,强调我的:
枚举(枚举)常量的一个问题是它们的数据类型经常是不确定的.换句话说,枚举常量不是可预测的unsigned int.对于传统构造的枚举,编译器实际上根据它找到的内容设置基础类型.底层类型可以是(signed)int或甚至long.请看以下示例:
type enum {
MyFlagError = -1,
MyFlagLow = 0,
MyFlagMiddle = 1,
MyFlagHigh = 2
} MyFlagType;
编译器查看此声明,并查找分配给其中一个成员常量的负值,声明枚举int的基础类型.如果成员的值范围不适合int或unsigned int,则基类型将静默地变为64位(长整数).因此,定义为枚举的基本类型数量可以无提示地更改大小以符合枚举中的值.无论您是编译32位还是64位,都会发生这种情况.不用说,这种情况对二进制兼容性提出了障碍.
作为解决此问题的补救措施,Apple已决定更加明确Cocoa API中的枚举类型.现在,头文件不是根据枚举声明参数,而是单独声明可以指定大小的枚举类型.枚举的成员及其值将像以前一样声明和分配.例如,而不是这样:
typedef enum {
NSNullCellType = 0,
NSTextCellType = 1,
NSImageCellType = 2
} NSCellType;
现在有这个:
enum {
NSNullCellType = 0,
NSTextCellType = 1,
NSImageCellType = 2
};
typedef NSUInteger …基本上我在NSInteger中存储数组的索引.我现在需要它作为NSIndexpath,我很难看到并找到一种方法将我的NSInteger转换为NSIndexpath,所以我可以重用它.