Sont les variables d'instance définie à zéro par défaut en Objective-C?

Je suis tri de certains problèmes de mémoire avec mon iPhone et je viens de penser à quelques notions de base. Si je configurer un ivar et ne jamais l'utiliser dans la durée de vie de mon objet, quand je l'appelle dealloc sur elle, cela cause un problème? E. g.

@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
  • Mike Abdullah: j'ai fait ce changement dans mon montage.
  • Ah bon, donc normale de la variable créée dans une fonction ne sont pas définis à 0/zéro lorsque vous les déclarez ensuite? Juste les variables d'instance. Donc, est-il exact que les variables normales sera juste contiennent des "ordures" jusqu'à ce que vous l'avez explicitement définie à quelque chose?
  • Qui est correct.
  • objet Local variables sont automatiquement initialisés à zéro.
  • ... lorsque vous utilisez un ARC, qui vous doit.
InformationsquelleAutor Michael Waterfall | 2009-11-23
  1. 56

    Variables d'Instance sont initialisées à 0 avant votre initialiseur fonctionne..

    InformationsquelleAutor Chuck
  2. 11

    Oui, ivars sont toujours initialisées à 0/nul/NULLE/NON/etc.

    Cependant, si elle vous aide à comprendre ce qu'il se passe, d'aller pour elle. L'impact sur les performances est négligeable. Vous n'avez pas besoin de le faire, mais il ne sera pas causer des problèmes si vous n'.

    • Je ne vois pas comment gaspillée, code redondant est une bonne pratique. Vous assurez-vous de régler l'ensemble des variables locales à la même valeur à plusieurs reprises dans une rangée juste pour le rendre vraiment explicite?
    • Pas de. La définition de variables locales à plusieurs reprises permettrait de réduire la clarté du code et d'augmenter la confusion. La définition explicite d'un ivar augmente la clarté, et un nouveau membre de l'équipe qui sont moins familiarisés avec objc comprendre plus facilement ce qui se passe. Code de la clarté est plus important que la réduction du "gaspillage" du code.
    • Objective-C, les développeurs devraient être familiers avec le zéro de l'initialisation de l'ivars. En raison de la réinitialisation de la init méthodes peuvent souvent être omis complètement, ce qui est une bonne chose. Si les développeurs sont encore en apprentissage, ils ne devraient pas apprendre ce concept de code, mais à partir d'un livre, d'instructeur, de SORTE que, ou que ce soit. Ils n'apprendraient pas ce concept par la lecture de code redondant, de toute façon.
    • C'est de mauvais conseils. Il n'y a absolument aucune raison de fixer votre ivars à néant.
    • Mise à jour de ma réponse à supprimer l'affirmation erronée que c'est la "bonne pratique" de le faire.
    • Pour battre un cheval mort un peu plus, pour les mettre à néant en fait augmente la confusion, parce que quand un knowlegable Cacao programmeur voit que, dit-il à lui-même, "Maintenant, pourquoi est-ce que le fait d'être mis à néant? Peut-être la super-classe définit-il à quelque chose, donc l'auteur de cette classe voulais annuler cela...maintenant, je dois aller le chercher"
    • Si vous avez plus d'un objet, et certains devraient être nul, et d'autres pas, c'est la peine de définir un objet de néant pour le rendre clair, vous saviez ce que vous faites. Par exemple _array1 = nil; _array2 = [NSMutableArray tableau]; _array3 = [NSMutableArray tableau]; de sorte que personne ne pense que vous avez oublié de matrice1.
    • "Définir explicitement un ivar augmente la clarté, et un nouveau membre de l'équipe qui sont moins familiarisés avec objc comprendre plus facilement ce qui se passe" Uggh. Jamais code pour un public de gens qui ne connaissent pas les rudiments de la langue. Souhaitez-vous également de mettre des commentaires ci-dessus méthode init expliquant ce init ne?

    InformationsquelleAutor BJ Homer
  3. 0

    Je trouve que c'est une bonne pratique de toujours régler ces ivars à nil dans le init méthode. De cette façon, vous êtes absolument sûr que votre appel à release dans le destructeur ne peut pas causer des problèmes.

    Si il s'avère que l'Objective-C n'est automatiquement mis à nil, et pour quelque raison que vous vous retrouvez avec un goulot d'étranglement de vitesse qui peut être amélioré par la suppression de ces affectations (très peu probable), alors vous pouvez vous soucier de la suppression d'eux. Dans l'intervalle, les mettre tous à nil et le sommeil plus facile 🙂

    mise à jour: BJ Homer et Chuck ont souligné que le ivars sera automatiquement mis à zéro, alors maintenant, c'est une décision sur le style.

    • Vous pouvez être sûr de toute façon. Juste une façon de votre méthode init est plein d'un affectations inutiles.
    • Merci pour votre réponse 🙂
    • Le meilleur code est le code que vous n'avez pas à écrire. Si une langue, des garanties, de faire usage d'entre eux. Si vous commencez à douter de la documentation de base de la langue (comme nilling de ivars), alors vous êtes dans un vrai trou de lapin.
    InformationsquelleAutor e.James