Что нужно знать об ARC

Можно не добавлять модификатор __autoreleasing в сигнатуру -(BOOL)save:(NSError * __autoreleasing *) error, т.к. переменная-указатель на id имеет этот модификатор по умолчанию.

Для блока нужно вызывать copy только если он все еще размещен на стеке, т.е. если блок объявлен вне метода это делать особого смысла нет.

NSString *a = (__bridge NSString*)my_cfref; // пустой каст

В этой строчке происходит увеличение количества ссылок, так как переменная имеет модификатор __strong.

Блоки по-прежднему необходимо копировать.

//локальная переменная
someBlockType someBlock = ^{NSLog(@"hi");}; 
[someArray addObject:[someBlock copy]];

Мне кажется, интересно разобрать этот момент подробнее.

Во-первых, почему нужно копировать? Потому что по-умолчанию блоки создаются в стеке, а не в куче, проверим:

    int i = 0;
    NSLog(@"%@",[^{NSLog(@"i = %d", i);} class]);
// __NSStackBlock__

Блок класса __NSStackBlock__, т.е по выходу из области видимости указатель на блок станет невалидным, поэтому нам надо скопировать его в кучу, тогда в массиве будет храниться верный указатель:

    int i = 0;
    NSLog(@"%@",[[^{NSLog(@"i = %d", i);} copy] class]);
//__NSMallocBlock__

Очевидно, в результате копирования мы получили блок в куче. Теперь его можно помещать в массив.

Но любопытно, если инициализировать блок через переменную, то копирование не обязательно, блок уже будет в куче.

    int i = 0;
    dispatch_block_t someBlock = ^{NSLog(@"i = %d", i);};
    NSLog(@"%@",[someBlock class]);
// __NSMallocBlock__

Почему так происходит? Потому что по-умолчанию для указателей на объекты (а блок — это объект) применяется модификатор __strong, т.е. код разворачивается в __strong dispatch_block_t someBlock = ...; затем при инициализации strong переменной объекту посылается retain, а в соответствии с документацией ARC такой retain для блоков разворачивается в Block_copy. Итого, блок уже в куче.

Кроме того, примитивные блоки без доступа к окружающему scope никогда не лежат в стеке, а определяются как глобальные константы, операции copy и release на них никак не влияют.

    NSLog(@"%@",[^{NSLog(@"hi");} class]);
    NSLog(@"%@",[[^{NSLog(@"hi");} copy] class]);
// __NSGlobalBlock__
// __NSGlobalBlock__

(Поэтому для предыдущих примеров мне понадобилось ввести переменную «i».)

Но, безусловно, всё равно лучше придерживаться правила всегда копировать блоки при передачи их за область видимости, где они были определены. Просто, понимая внутренние процессы, запомнить это правило по-моему проще.

Важная и полезная особенность ARC: сразу после деаллокации слабые и сильные ссылки обнуляются, то есть становятся равными nil.

Сильные в эту фразу очевидно случайно попали, ибо если они не nil, то какая тогда деаллокация?

Ну и технически, если кому интересно, не при деаллокации ссылки обнуляются, а при использовании слабой ссылки вызывается функция objc_loadWeak (или аналог), которая проверяет, жив ли ещё объект, и загружает его. К слову, слабые ссылки из-за этого относительно медленные. Но не настолько, чтобы их опасаться. :) Это определенно очень крутая и на мой взгляд самая полезная штука во всём ARC. Можно отказаться от ручного управления только ради них, если остальное вас не привлекает.

О циклических ссылках компилятор предупредит

На компилятор надейся, да сам не плошай. Компилятор видит далеко не всё, пример вчера приводил. Одна из частых ошибок — использование переменных экземпляра в блоке, в результате чего также ретейнится объект. ( _i эквивалентно self->_i )

Простите за глупый вопрос, вот тут:

__weak SomeObjectClass *weakSelf = self;
SomeBlockType someBlock = ^{
SomeObjectClass *strongSelf = weakSelf;
if (strongSelf) {
[strongSelf someMethod];
}
};

можно же обойтись без strongSelf, просто используя weakSelf?

К сожалению, не всегда есть возможность использовать ARC. Например, при написании скринсейвера для 10.7 — только GC-compatible, а он не совместим с ARC.

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

Используйте ARC. Это проще, безопаснее и сэкономит вам время и нервы.

Ха ха. Сегодня с другом разбирали пол дня его проблему. В итоге ARC создан чтобы не следить за памятью. Но в некоторых случаях он сбоит и нужно то закэшировать переменную, то ещё чего, чтобы он не вставил dealloc. ИМХО найти проблемное место, и то что оно возникает куда большая проблема, чем писать сразу явно, тогда не будет вопросов, или использовать другой язык. Он новичек, а я вообще на object c и swift не пишу, не знали про такие грабли, спасибо за статью, я думал это баг. В следующий раз будем знать куда копать, но это костыли какие то, подкручивать счётчики когда он сам не справляется, а это узнаешь постфактум, зачем он тогда нужен, если полагаться нельзя.

не очень понял этот код

id cachedObject = self.delegate;
if (cachedObject) {
	[self.delegate doSomeTask];
}
cachedObject = nil;

возможно хотелось что-то такое?

id cachedObject = self.delegate;
if (cachedObject) {
	self.delegate = nil;
	[cachedObject doSomeTask];
}