Desactivar de manera compacta la advertencia de arc-retain-cycles para bloques que se auto referencian

Question

Estoy escribiendo una API que implica el manejo de eventos, y me gustaría poder usar bloques para los manejadores. Las devoluciones de llamada a menudo querrán acceder o modificarse. En el modo ARC, Clang advierte que los bloques que hacen referencia a uno mismo probablemente creen un ciclo de retención, lo que parece una advertencia útil que quiero mantener en general.

Sin embargo, para esta parte de mi API, el ciclo de vida de la devolución de llamada y el objeto que contiene se mantienen de forma externa. Sé que puedo romper el ciclo cuando el objeto debe ser desasignado.

Puedo desactivar la advertencia de retener ciclo por archivo con #pragma clang diagnostic ignored "-Warc-retain-cycles", pero eso desactiva la advertencia para todo el archivo. Puedo rodear los bloques con #pragma clang diagnostic push y pop alrededor de esa advertencia, pero eso hace que los bloques sean feos.

También puedo obtener la advertencia de que se va al hacer referencia a una variable __weak que apunta a self en lugar de hacer referencia directamente a self, pero eso hace que los bloques sean menos agradables de usar.

La mejor solución que he llegado con esta macro es que hace el diagnóstico de discapacidad en todo el bloque:

#define OBSERVE(OBJ, OBSERVEE, PATH, CODE) \ 
[(OBJ) observeObject:(OBSERVEE) forKeyPath:(PATH) withBlock:^(id obj, NSDictionary *change) { \ 
_Pragma("clang diagnostic push") \ 
_Pragma("clang diagnostic ignored \"-Warc-retain-cycles\"") \ 
do { CODE; } while(0); \ 
_Pragma("clang diagnostic pop") \ 
}]; 

que funciona, pero no es muy visible para los usuarios de la API, que no permite anidada observadores, e interactúa mal con el editor de XCode. ¿Hay una mejor manera de desactivar o evitar la advertencia?

Answer 1

Para empezar, hay una forma sencilla de desactivar las advertencias para ciertas líneas de código usando #pragma:

#pragma clang diagnostic push 
#pragma clang diagnostic ignored "<#A warning to ignore#>" 
<#Code that issues a warning#> 
#pragma clang diagnostic pop 

Pero no lo utilizaría en este caso particular, porque no va a solucionar el problema , simplemente lo ocultará al desarrollador. Preferiría ir con la solución que Mark propuso. Para crear una referencia débil, se puede hacer una de las siguientes exterior del bloque:

__weak typeof(self) weakSelf = self; // iOS ≥ 5 
__unsafe_unretained typeof(self) unsafeUnretainedSelf = self; // 5 > iOS ≥ 4 
__block typeof(self) blockSelf = self; // ARC disabled 

Answer 2

la nueva LLVM es mejor para detectar/prevenir tales conservan ciclos esperar el envío LLVM con iOS6 o hacer camino de Alex con la creación una var. débil

¡desactivar la advertencia es una mala idea!

Answer 3

Creo que desactivar la advertencia es actualmente la única forma correcta de hacerlo, ya que dice el compilador: No me importa este ciclo de retención, soy consciente de ello y me deshago del observador yo mismo. Introducir una referencia débil es una solución costosa, ya que viene con CPU y memoria en tiempo de ejecución.

Answer 4

me escribió la siguiente macro, que Creo, es muy inteligente ...

#define CLANG_IGNORE_HELPER0(x) #x 
#define CLANG_IGNORE_HELPER1(x) CLANG_IGNORE_HELPER0(clang diagnostic ignored x) 
#define CLANG_IGNORE_HELPER2(y) CLANG_IGNORE_HELPER1(#y) 

#define CLANG_POP _Pragma("clang diagnostic pop") 
#define CLANG_IGNORE(x)\ 
    _Pragma("clang diagnostic push");\ 
    _Pragma(CLANG_IGNORE_HELPER2(x)) 

Se le permite hacer todo tipo de cosas divertidas (sin Xcode que arengando), tales como ..

CLANG_IGNORE(-Warc-retain-cycles) 
[object performBlock:^(id obj){ [obj referToSelfWithoutWarning:self]; }]; 
CLANG_POP 

Usted puede poner en cualquier bandera de advertencia y Clang va prestar atención a sus caprichos ...

CLANG_IGNORE(-Warc-performSelector-leaks); 
return [self performSelector:someIllBegotSelector withObject:arcFauxPas]; 
CLANG_POP 

Por otra parte, las advertencias por lo general están ahí por una razón. Petardos.

Answer 5

Para resolver el problema del chasquido de crear una referencia débil, puse eso en una macro. Se utiliza el preprocesador para crear una nueva var con el mismo nombre pero con un prefijo ('w', en este caso, he evitado 'débil' porque eso sería una exageración y el desorden más con las reglas de capitalización):

#define WEAK_VAR(NAME) __unsafe_unretained typeof(NAME) w##NAME = NAME 

... 
WEAK_VAR(self); 
self.block = ^{ 
    [wself doStuff]; 
}; 

Si, otoh, una referencia débil no es deseable, ¡no la use! Me gusta la solución de Nielsbot de pasar el objeto como un parámetro (cuando sea posible, por supuesto).