@property pour le type int?

Question

Juste une petite question, si je peux me permettre, je l'ai toujours (depuis l'apprentissage obj-c) écrit propriétés int comme suit ...

@property(nonatomic, assign) int myValue; 

Je pense maintenant que cela pourrait être exagéré et je pourrais aussi bien écrire ...

@property int myValue; 

Juste curieux, je sais que « affecter » est le comportement par défaut et que « nonatomic » peut être très légèrement plus rapide ...

le meilleur

Gary

Answer 1

Eh bien, la question de déclarer atomicité est une distincte de savoir si vous explicitement déclare les attributs qui sont les attributs par défaut. Le premier dépendra de la nature de votre code - y aura-t-il un accès multithread contentieux à la propriété? En ce qui concerne ce dernier, c'est surtout une question de style, mais en général, je pense que vous devez pécher du côté de la clarté explicite. Exactement combien de secondes de votre vie cela vous coûte-t-il de taper ces quelques touches supplémentaires?

Answer 2

Nonatomic génère moins de code et est légèrement plus rapide. Je suis d'accord que c'est très verbeux cependant.

Si votre application peut utiliser plusieurs threads, vous serez heureux d'avoir mis ces qualificatifs explicites lorsque vous rencontrez des bugs étranges ...

Answer 3

@property(nonatomic, assign) int myValue; 

n'est pas la même chose que

@property int myValue; 

La valeur par défaut pour une propriété est atomique (il n'y a pas de mot clé explicite atomic). Donc le deuxième exemple est une propriété atomique. Pour une propriété de type primitif, je ne sais pas si un verrouillage se produit, mais une barrière d'écriture en mémoire sera probablement introduite (le setter forcera la valeur à être réécrite dans la mémoire principale, au lieu de seulement dans le cache). Ainsi, les propriétés atomiques sont considérablement plus lentes que les propriétés non atomiques. Cependant, en tant que fraction du temps d'exécution total du programme, ils pourraient représenter un très petit pourcentage. Vous ne saurez pas jusqu'à ce que vous définissiez votre code.