duración de las variables locales débiles con ARC

Question

Si tengo un trozo de código que se parece a esto:

- (void)testSomething 
{ 
    __weak NSString *str = [[NSString alloc] initWithFormat:@"%@", [NSDate date]]; 
    NSLog(@"%@", str); 
} 

la salida será (nulo) ya que no existen fuertes referencias a str y se dará a conocer de inmediato después de asignarlo. Esto tiene sentido y se explica en la guía Transición a ARC.

Si mi código es el siguiente:

- (void)testSomething 
{ 
    __weak NSString *str = [NSString stringWithFormat:@"%@", [NSDate date]]; 
    NSLog(@"%@", str); 
} 

luego imprime correctamente a la fecha actual. Obviamente, esperaría que funcionara en un mundo que no sea ARC, ya que str se lanzaría automáticamente y, por lo tanto, sería válido hasta que este método finalice. Sin embargo, en el código habilitado para ARC, las personas generalmente consideran que los dos formularios (stringWithFormat & alloc/initWithFormat) son equivalentes.

Así que mi pregunta es si el código como el segundo ejemplo está garantizado para trabajar bajo ARC. Es decir, si tengo una referencia débil a un objeto que obtengo a través de lo que normalmente consideraríamos un constructor de conveniencia de autorrelleno, ¿está seguro de para usar esa referencia en el mismo alcance que normalmente tendría sin ARC (es decir, hasta que el método sale)?

Answer 1

Las convenciones de autorrelleno y asignación siguen aplicando en el mundo de ARC. La única diferencia es que ARC insertará llamadas de retención/liberación adicionales para que sea mucho más difícil filtrar objetos o acceder a un objeto desasignado.

En este código:

__weak NSString *str = [[NSString alloc] initWithFormat:@"%@", [NSDate date]]; 

El único lugar se retiene el objeto (o equivalente) es la alloc. ARC insertará automáticamente un comando de liberación, haciendo que se desasigne inmediatamente.

Mientras tanto, en este código:

__weak NSString *str = [NSString stringWithFormat:@"%@", [NSDate date]]; 

Por convención, el valor de retorno de un constructor de conveniencia como esto debe ser un objeto autoreleased *. Eso significa que el grupo de liberación automática actual ha retenido el objeto y no lo liberará hasta que se drene el conjunto. Por lo tanto, está seguro de que este objeto existirá durante al menos la duración de su método, aunque probablemente no deba confiar en este comportamiento.

(* o retenido de alguna otra manera)

Answer 2

La vida útil de una variable débil local no está garantizado en absoluto. Si el objeto al que apunta la variable se desasigna, la variable débil apuntará a nil después.

Si tiene una referencia débil a un objeto que obtuvo a través de un método que no devuelve un objeto retenido, es no seguro para suponer que este objeto vive hasta que el método finalice. Si quiere asegurarse de que el objeto sobrevive, use una referencia fuerte.

Aquí es un ejemplo que muestra que el valor de retorno de un método no retención no está garantizada para terminar en la piscina autorelease:

• Crear un nuevo proyecto IOS (Single Ver App utilizando ARC y guiones gráficos)

• Añadir este método para la AppDelegate.m:

  + (id)anObject 
  { 
      return [[NSObject alloc] init]; 
  } 
  

• Reemplazar -application:didFinishLaunchingWithOptions::

  - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions 
  { 
      __weak id x = [AppDelegate anObject]; 
      NSLog(@"%@", x); 
      return YES; 
  } 
  

• Importante: Ahora ajustar el nivel de optimización para la depuración de -Os.

En este ejemplo, +[AppDelegate anObject] actúa como un constructor de conveniencia, pero verá (null) registra si se ejecuta en un dispositivo con -Os optimización. El motivo es una ingeniosa optimización de ARC que evita la sobrecarga de agregar el objeto al grupo de autorrelease.

Puede haber notado que cambié a no usar un método de biblioteca como +[NSString stringWithFormat:]. Estos parecen poner siempre objetos en el grupo de autorrelease, que puede ser por razones de compatibilidad.