2011-12-07 3 views
1

Я блуждал, как долго я могу освободить свою сохраненную собственность в своем методе dealloc. Для наглядности, здесь приведен пример кода:Как освободить сохраненное свойство

@interface MyClass: NSObject 
{ 
    //... 
    NSString *myStr; 
    //... 
} 

@property (retain, nonatomic) NSString *myStr; 
//... 

@end 

@implementation MyClass 

@synthesize myStr; 
//... 

//version 1 of dealloc 
-(void)dealloc 
{ 
    [myStr release]; 
    //... 
} 

//version 2 of dealloc 
-(void)dealloc 
{ 
    self.myStr = nil; 
} 

//... 
@end 

Как вы можете видеть, в моем примере кода две версии метода dealloc. Насколько мне известно, первый из них приводит к меньшему количеству машинного кода, чем второй, и, следовательно, быстрее. Но я когда-то слышал, что это хорошая привычка распоряжаться сохраненным имуществом вторым способом, то есть установить его на ноль, вызвав сеттер, используя ключевое слово self. Может ли кто-нибудь сказать мне, все ли это правда, и если это так, я должен придерживаться «хорошей привычки» или просто сделать свой код быстрее независимо от «хорошей привычки»?

Заранее спасибо.

ответ

2

Если у вас есть опция, the first choice is better, потому что у нее меньше побочных эффектов. Но вопрос о скорости почти наверняка не имеет отношения к какому-либо реальному применению. Скорость доступа к объекту по сравнению с release в dealloc просто не окажет заметного влияния на вашу программу. (Если ничего другого, стоимость выделения объекта в первую очередь dwarfs any performance gain, вы можете надеяться получить от бритья несколько сообщений, отправленных с dealloc, так что если бы вы были настоящей проблемой, лучшим подходом было бы сокращение ассигнований.)

+0

Получил это и поблагодарил. Я узнал, что «self.myStr = nil;» будет «[myStr release]; myStr = nil;» (здесь два утверждения). Поэтому я решил, что «[myStr release]» (одно заявление) будет быстрее. Кстати, «побочные эффекты», что именно вы имеете в виду здесь? – xuxu

+0

@xuxu: уведомления KVO, изменения в стеке отмены - вот что. – Chuck

Смежные вопросы