2010-03-25 5 views
0

Je me suis fait attraper par le bug suivant encore et j'aimerais obtenir des éclaircissements sur la raison pour laquelle c'est un bug.EXC_BAD_ACCESS lorsque vous n'utilisez pas self

J'ai simple UITableView qui charge certaines données:

// myclass.h 
@property (nonatomic, retain) NSArray *myData 

// myclass.m 
@synthesize myData; 

- (void) viewDidLoad { 
    ... 
    myData = someDataSource // note the lack of self 
} 

- (UITableViewCell *) cellForRowAtIndexPath ... { 
    ... 
    cell.textLabel.text = [self.myData objectAtIndex:indexPath.row]; // EXC_BAD_ACCESS 
} 

La première table des charges bien, mais lors du défilement jusqu'à assez que l'une des cellules est totalement hors de la vue que je puis obtenir le EXC_BAD_ACCESS Erreur. Suis-je manquant quelque chose en ce qui concerne @ conserver la propriété. Ma compréhension est qu'il libère tout ce que le pointeur indiquait avant la réaffectation. Si j'ai raison, pourquoi ne pas utiliser soi-même. causer des problèmes?

Merci pour l'aide.

**** Mise à jour

Pourquoi est que dans tous les exemples que j'ai vérifié avec la libération des objets dans la méthode dealloc sans l'auto?

- (void) dealloc { 
    [someArray release]; 
    [someTableView release]; 
} 

Répondre

1

Si vous n'utilisez pas self., vous êtes directement assignant à la variable d'instance myData, qui n'a rien à voir avec la propriété myData.

self.myData est juste du sucre syntaxique pour [self myData] ou [self setMyData:newValue], et la propriété synthétisé crée simplement les méthodes -myData et -setMyData:.

La variable d'instance est juste une variable, rien de plus. Bien qu'il puisse avoir le même nom, l'assigner à lui ou lire à partir de lui est comme accéder à n'importe quelle variable: rien n'est retenu, libéré, ou autrement modifié en dehors de l'assignation.

+0

je me rends compte qu'ils sont des méthodes, mais sont-ils pas seulement des emballages autour de la variable myData? Je suppose que la question est pourquoi myData = ... se perdre? – chris

+0

@chris, vous devez appeler la méthode pour que 'retain' se produise - vous mettez une fin de course sur le système en n'ayant pas' self.' dedans. –

+0

Pas vraiment, Carl. Ils ne l'enveloppent pas, ils lui spécifient une interface. Et cette interface arrive à conserver et libérer ce que vous lui donnez. Mais l'affectation aux variables ne l'est pas. Pensez à cette façon: les variables sont en C, donc l'assignation fonctionne comme en C, rien de plus. Mais les messages ne le sont pas, donc ils peuvent faire plus que ce qui est en C. –

1

En cas de

myData = someDataSource; 

vous donnez la référence de someDataSource (une variable locale ou variable de portée limitée) à myData. Maintenant, dès que someDataSource sort du champ d'application, il est libéré et comme vous avez passé sa référence à myData, il est également publié.

maintenant dans le cas de

self.myData = someDataSource; 

la valeur de someDataSource est affecté à myData. Par conséquent, tout ce qui arrive à someDataSourcemyData conservera la valeur.

Vous pouvez aussi le faire autrement:

myData = [someDataSource retain]; 

Hope this helps.

Merci,

Madhup

Questions connexes