2009-11-23 18 views
37

Estoy solucionando algunos problemas de memoria con mi aplicación de iPhone y he estado pensando en algunos conceptos básicos. Si configuro un ivar y nunca termino usándolo en la vida útil de mi objeto, cuando llamo a dealloc, ¿eso causará un problema? P.ej.¿Las variables de instancia están establecidas en nulo por defecto en Objective-C?

@interface testClass { 
    id myobject; 
} 
@property (nonatomic, retain) id myobject; 
@end 

@implementation testClass 
@synthesize myobject; 
- (id)init { 
    ... 
    // Do I have to set myobject to nil here? 
    // So if myobject isn't used the dealloc call to nil 
    // will be okay? Or can you release the variable without 
    // having set every object to nil that you may may not use 
    ... 
} 

... 

// Somewhere in the code, myobject may be set to 
// an instance of an object via self.myobject = [AnObject grabAnObject] 
// but the object may be left alone 

... 

- (void)dealloc { 
    [myobject release]; 
    [super dealloc]; 
} 
@end 
+0

Mike Abdullah: He hecho de que el cambio en mi edición. –

+0

Ah, ¿correcto, entonces las variables normales creadas en una función no están configuradas en 0/nil cuando las declaras entonces? Solo variables de instancia. Entonces, ¿es correcto que las variables normales contengan 'basura' hasta que lo establezcas explícitamente? –

+0

Eso es correcto. –

Respuesta

0

Me parece que es una buena práctica siempre se establece esos ivars a nil en el método init. De esta forma, está absolutamente seguro de que su llamada al release en el destructor no puede causar problemas.

Si resulta que Objective-C los configura automáticamente en nil, y por algún motivo se encuentra con un cuello de botella de velocidad que se puede mejorar eliminando esas asignaciones (muy poco probable), puede preocuparse por eliminar ellos. Mientras tanto, a todos ellos se establece en nil y dormir más fácil :)

actualización: BJ Homero y Chuck han señalado que los Ivars se ajustará automáticamente a cero, por lo que ahora todo se reduce a una decisión sobre estilo.

+3

Puede estar seguro de cualquier manera. Solo una forma en que tu método init está lleno de asignaciones inútiles. – Chuck

+0

Gracias por su respuesta :-) –

+0

El mejor código es el código que no tiene que escribir. Si un lenguaje hace garantías, haz uso de ellas. Si empiezas a dudar de la documentación de los fundamentos del lenguaje (como el nilling de ivars), entonces estás en un verdadero agujero de conejo. – occulus

11

Sí, ivars are always initialized to 0/nil/NULL/NO/etc.

Sin embargo, si te ayuda a entender lo que está pasando, hazlo. El impacto en el rendimiento es insignificante. No necesita hacerlo, pero no causará ningún problema si lo hace.

+10

No veo lo desperdiciado, el código redundante es una buena práctica. ¿Se asegura de configurar todas las variables locales con el mismo valor varias veces seguidas solo para hacerlo realmente explícito? – Chuck

+11

No. Establecer variables locales varias veces reduciría la claridad del código y aumentaría la confusión. Establecer explícitamente un ivar aumenta la claridad, y un nuevo miembro del equipo menos familiarizado con objc entiende más fácilmente lo que está sucediendo. La claridad del código es más importante que la reducción del código "desperdiciado". –

+2

Los desarrolladores de Objective-C deben estar familiarizados con la inicialización cero de ivars. Debido a la reducción a cero, los métodos de 'init' a menudo se pueden omitir por completo, lo cual es algo bueno. Si los desarrolladores aún están aprendiendo, no deberían aprender este concepto del código, sino de un libro, instructor, SO o lo que sea. Sin embargo, no aprenderían este concepto leyendo códigos redundantes. –

Cuestiones relacionadas