Dénomination Dotloc?

@property (copy) NSString *name; 
@property (copy) NSString *orbit; 
@property (copy) NSNumber *mass; 
@property float surfaceTemp; 
@property float rotationSpeed;

Actuellement Avez-ceDénomination Dotloc?

- (void)dealloc{ 
    [name release]; 
    name = nil; 
    [orbit release]; 
    orbit = nil; 
    [mass release]; 
    mass = nil; 
    [super dealloc]; 
}

Si j'écris ceci en utilisant la notation Dot (Objective-C 2.0) Est-ce exact?

- (void)dealloc{ 
    self.name = nil; 
    self.orbit = nil; 
    self.mass = nil; 
    [super dealloc]; 
}

gary

Source

2009-10-01 fuzzygoat

Petite astuce: vous pouvez réduire le nombre de lignes de code dans votre méthode 'dealloc' en procédant comme suit:' [name release], name = nil; '. Juste une petite chose de mise en forme, mais je pense que c'est plus facile à lire. – Alex

Merci Alex, je vais utiliser cela, très apprécié. – fuzzygoat

Il n'y a pas vraiment besoin d'éliminer un ivar pendant un dealloc. Logiquement, vous définissez la valeur d'une variable sur un objet que vous savez déjà être sur le point d'être détruit. Il y a un argument à faire là-bas pour des raisons de cohérence avec le reste de votre code, je suppose. Une façon raisonnable de procéder est une macro de version, comme ceci: #define TT_RELEASE (__ P) {[__P release]; __P = nul; } –

Il est une mauvaise pratique d'utiliser vos méthodes setter dans -dealloc. Utilisez [name release] à la place.

L'établissement de paramètres pendant -dealloc peut avoir des conséquences imprévues. Si vous utilisez KVO, la définition de propriétés peut déclencher l'exécution d'autres codes provoquant des effets secondaires, car votre objet a déjà commencé à libérer des variables d'instance. Même si vous n'utilisez pas KVO, cela peut causer des problèmes potentiels si votre méthode de réglage utilise d'autres variables d'instance qui ont déjà été libérées.

(mis à jour pour tenir compte des commentaires)

Source

2009-10-01 17:10:46 pix0r

Je l'avais déjà lu, mais uniquement en ce qui concerne l'utilisation d'init, en raison d'un objet potentiellement partiellement initialisé. Pourquoi sont-ils mauvais à utiliser dans dealloc? – nall

J'ai cherché la référence, mais pour être honnête, je ne sais pas pourquoi cela est mal vu. Je sais juste que j'ai été corrigé parce que j'avais l'habitude de faire la même chose. La seule chose que je peux penser est que votre méthode de setter peut dépendre d'autres ivars ou propriétés qui ont déjà été libérées. – pix0r

@nall Si vous avez d'autres objets utilisant KVO pour observer les modifications apportées aux propriétés de cet objet, l'utilisation des accesseurs dans un dealloc peut provoquer des choses intéressantes (comme les observateurs qui tentent de manipuler un objet partiellement détruit). Plus d'infos: http://stackoverflow.com/questions/1283419 –

Dans mon expérience self.name = nil ne fait pas la même chose que [name release]; name = nil. Ma conjecture est qu'il y a du code dans le setter synthétisé qui évite les affectations nil, mais YMMV. Les propriétés que j'ai observées ont également été spécifiées (nonatomic, retain) donc vous pourriez voir quelques différences là aussi. De plus, la notation self. envoie des notifications KVO, il y a donc une pénalité de performance à considérer dans ce cas également.

Source

2009-10-01 17:14:23 fbrereto

Intéressant, savez-vous s'il y a un surdébit lors de l'utilisation de cette notation dans main(), c'est-à-dire si vous accédiez à obj.name = @ "mr happy"; comme apposé à la plus traditionnelle [obj setName: @ "mr happy"]; – fuzzygoat

Les cas d'utilisation que vous avez mentionnés sont l'équivalent. – fbrereto

sont l'équivalent car ils ajoutent une pénalité de performance? – fuzzygoat

Dénomination Dotloc?

Répondre

Questions connexes