ARC и пользовательские сделки

Question

Из любопытства / волнения я читал любую информацию, которую я могу найти о ARC, но у меня есть один вопрос, на который я не могу найти ответ.Не уверен, что люди могут ответить на это из-за NDA или чего-то еще, но я все равно спрошу.(Там много информации .......)

ARC рекламирует одну вещь: вам больше не нужно писать методы dealloc.Здорово.Но так ли это на самом деле?

Если у меня есть NSNetService или что-то еще, обычно в моем dealloc я бы написал

- (void)dealloc
{
    [netService_ setDelegate:nil];
    [netService_ stop];
    [netService_ release];

    [super dealloc];
}

А ARC позаботится об этом сейчас?Или не достаточно умен, чтобы знать о таких вещах?Если он не достаточно умен, чтобы знать об этом (то есть, в некоторых случаях мне все равно придется писать собственные разборки), должен ли я выпустить все ivars?Или просто те, которые не будут простыми выпусками?

- (void)dealloc
{
    [netService_ setDelegate:nil]; // if these 3 lines are necessary...
    [netService_ stop];
    [netService_ release];

    [myString_ release]; // would this one still be? or would ARC know to automagically add this
    [super dealloc]; // seems this is forbidden in ARC
}

Полагаю, мой вопрос действительно сводится к следующему: ARC говорит, что вам больше не придется писать колллоки в большинстве случаев;так когда же дела должны?

Answer 1

Насколько я понимаю, вы должны думать о ARC как о статическом анализаторе, встроенном в компилятор, который синтезирует вызовы retain и release при необходимости (что также является причиной того, что код ARC будет обратно совместим с устройствами, работающими iOS4).

Так что netService_ в вашем образце не будет остановлено автоматически. В этом случае вам нужно будет написать свой собственный dealloc.

Проблема с делегатом интересна, в iOS5 она будет слабым свойством, поэтому ее можно установить равной нулю на dealloc ... Не уверен, но это интересно!

Еще один случай, который вам придется взять на себя, это то, что у вас есть дескрипторы объектов, которые не являются объектами c-объекта, например, для объектов Core Foundation вам нужно написать CFRetain s и CFRelease s самостоятельно.

Answer 2

Я думаю, что если есть что-то, что вам нужно сделать для очистки объекта, , отличное от , кроме его освобождения, является честной игрой для пользовательского метода dealloc.

Так что в вашем собственном примере с netService_ было бы разумно звонить на setDelegate: и stop, но не было бы необходимости звонить release, потому что ARC позаботится об этом.

Answer 3

Понятно, что ARC не будет знать о вашей [netService_ stop]; линии. Вы должны включить это самостоятельно, так как это нестандартно и не имеет отношения к retain / release.

Сразу после запуска dealloc ARC высвободит все свойства strong и weak (и __strong и __weak iVars).

Вот некоторый тестовый код, просто чтобы посмотреть, что происходит:

@interface TestClass : NSObject

@property (nonatomic, strong) TestClass *anotherTestObject;

@end


@implementation TestClass
@synthesize anotherTestObject;

- (void)dealloc {
    NSLog(@"I am deallocing %d", self.hash);
}

@end

И мой тест:

TestClass *thing1 = [[TestClass alloc] init];
NSLog(@"thing 1 %d", thing1.hash);

thing1.anotherTestObject = [[TestClass alloc] init];
NSLog(@"thing 2 %d", thing1.anotherTestObject.hash);

Это распечатает что-то вроде этого

thing 1 1450176
thing 2 1459984
I am deallocing 1450176
I am deallocing 1459984

Поскольку только один из объектов автоматически освобождается (thing1) в конце тестового кода, вы можете сразу сказать, что thing2 выпускается кем-то другим (так как он находится в свойстве strong). Однако, если вы перезаписаете setAnotherTestObject, вы обнаружите, что ARC не устанавливает его на nil, а просто просто освобождает его напрямую. Вы не можете переопределить release в ARC, иначе я мог бы продемонстрировать это тоже;)

Если я корректирую код и использую weak вместо strong, то же поведение сохраняется, но выходные данные отличаются, поскольку тестовый пример вообще не удерживает слабую ссылку.