2013-05-07 74 views
2

我有一个使用MRC(非ARC)静态库的启用ARC的应用程序。在静态库中,retain/release被覆盖以提供一些自定义的弱引用/缓存行为(当然称为[super retain/release])。问题是由于retain/release在启用ARC的代码中不允许,可以使用在启用ARC的代码中覆盖retain/release的类吗?目前它似乎运行良好,但我不确定这是否依赖未定的行为,这可能会在未来破裂。覆盖保留/释放在ARC

还有什么理由禁止优先retain/release?是否因为编译器做了一些特殊的优化,绕过了消息绑定过程来加速方法调用?我知道_objc_storeStrong调用是由引用计数的编译器生成的,那么这是否意味着重写的retain/release不能保证在ARC下调用?

+0

ARC只是自行维护内存管理,即以简单的语言根据对象的范围自动放入保留/释放代码。所以,只要不担心图书馆不启用ARC,它将不会在将来创建任何问题。 – 2013-05-07 11:54:57

回答

6

只要类没有ARC(您可以通过文件的基础文件控制编制;去构建阶段,并作为一个标志添加-fno-objc-arc到应该编译MRR的任何文件在ARC'd项目中),那么MRR编译的类可以将保留/释放/自动释放覆盖到他们心脏的内容。

在ARC下保留/释放/ autorelease是verboten,因为ARC被设计为在编译时为你处理所有的内存管理,同时也迫使你将内存管理与看起来可以堆积到内存管理上的其他角色分开,但是真的不属于那里。

例如,release的最典型覆盖涉及检查retainCount,如果是2,则转换为1意味着“将该对象放回缓存中供以后检索”,而缓存负责最终的保留对该对象的引用。

它可以工作,但它非常脆弱,有更好的解决方案,不涉及与内存管理共谋缓存。

-4

覆盖保留/释放不正确。但如果你需要它:

-(id)retain 
{ 
    NSIncrementExtraRefCount(self); 
    return self; 
} 

-(void)release 
{ 
    if(NSDecrementExtraRefCountWasZero(self)) 
    { 
     NSDeallocateObject(self); 
    } 
} 

-(id)autorelease 
{ // Add the object to the autorelease pool 
    [NSAutoreleasePool addObject:self]; 
    return self; 
} 

我还没有测试他们的ARC。和原来的文章: link

+0

和我的答案有什么问题? – user2159978 2013-05-07 13:43:22

+7

您无法在ARC中覆盖保留/释放。而且,即使你可以,这也不能回答这个问题。 – bbum 2013-05-07 17:20:45

+0

和?我不能标记这个类只能使用没有ARC? – user2159978 2013-05-18 14:30:12