大佬教程收集整理的这篇文章主要介绍了objective-c – 在objc ARC下用-Os过度释放,而不是-O0，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。
以下代码示例导致在使用编译器优化(-Os)构建时由于过度释放导致崩溃,但在关闭编译器优化(-O0)时不会崩溃.该项目正在使用Xcode 4.4.1(4F1003),Apple LLVM编译器4.0@H_696_3@
当num2被过度释放时,应用程序崩溃.启用僵尸对象以确认是这种情况.@H_696_3@
// This crashes under -Os,but not under -O0 NSnumber *num1 = @((float)arc4random() / (float)UINT32_MAX); NSnumber *num2 = @((float)arc4random() / (float)UINT32_MAX); NSnumber *foo1 = num1; NSnumber *foo2 = num2; for (NSUInteger i=0; i<2; i++) { NSLog(@"foo1: %p %@",foo1,foo1); NSLog(@"foo2: %p %@",foo2,foo2); // swap foo1 and foo2 foo1 = num2; foo2 = num1; }
num1和num2应保证指向实例的使用寿命.我怀疑优化器是[正确]重复使用堆栈槽,并且[错误地]发出导致该问题的版本/保留序列.@H_696_3@
响应栈主它是一个编译器错误. ARC的全部要素是将Objective-C转换为编译器可以100％确定性地分析代码,以了解保留/发布的位置,以便您,开发人员不必.总而言之,即使面对线程,即使在使用MRR世界中的对象的所有代码都表现良好,开发人员也不会将对象从ARC控制中“逃脱”做一些调皮两个大的ifs,但是对MRR的巨大改进.@H_696_3@
最后,如果您的代码在优化时无效(当没有编译器错误发挥时),这是因为您的代码已损坏.正确编写的优化器不会打破正确的代码.@H_696_3@
虽然一些编译器臭名昭着,但LLVM并不是其中的一个(我不会就GCC提出索赔,因为我几年没有使用,但是我敢打赌也可以这样说). iOS或OS X系统将在每次启动时执行数百万和数百万行的编译与优化启用代码,并且系统工作得很好.@H_696_3@
所以,不,“优化器被打开”从来没有崩溃的最终解决方案.@H_696_3@
正如Catfish_man所说,有一些深奥的优化器选项将有意义地产生技术上错误的代码.它们未被-O或其他“标准”优化启用.它们主要集中在数学运算上,因此通常不会导致崩溃,同样更快的错误蠕变到计算中.@H_696_3@
以上是大佬教程为你收集整理的objective-c – 在objc ARC下用-Os过度释放,而不是-O0全部内容，希望文章能够帮你解决objective-c – 在objc ARC下用-Os过度释放,而不是-O0所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。