Il n'y a aucun inconvénient. Utilise le. Fais-le aujourd'hui. C'est plus rapide que votre ancien code. C'est plus sûr que votre ancien code. C'est plus facile que votre ancien code. Ce n'est pas un ramassage des ordures. Il n'a pas de surcharge d'exécution du GC. Les inserts du compilateur conservent et publient dans tous les endroits que vous devriez avoir de toute façon. Mais il est plus intelligent que vous et peut optimiser ceux qui ne sont pas réellement nécessaires (tout comme il peut dérouler des boucles, éliminer des variables temporaires, des fonctions en ligne, etc.)
OK, maintenant je vais vous parler des petits inconvénients:
Si vous êtes un développeur ObjC de longue date, vous vous contracterez pendant environ une semaine lorsque vous verrez du code ARC. Vous vous en remettrez très vite.
Il y a quelques (très) petites complications dans le pontage vers le code Core Foundation. Il y a un peu plus de complications dans le traitement de tout ce qui traite un idcomme void*. Des choses comme les tableaux C de idpeuvent prendre un peu plus de réflexion pour faire correctement. Une manipulation sophistiquée d'ObjC va_argspeut également causer des problèmes. La plupart des choses impliquant des mathématiques sur un pointeur ObjC sont plus délicates. Vous ne devriez pas en avoir beaucoup de toute façon.
Vous ne pouvez pas mettre un iddans un struct. C'est assez rare, mais parfois utilisé pour emballer des données.
Si vous n'avez pas suivi la dénomination KVC correcte et que vous mélangez du code ARC et non-ARC, vous aurez des problèmes de mémoire. ARC utilise la dénomination KVC pour prendre des décisions sur la gestion de la mémoire. Si c'est tout du code ARC, alors cela n'a pas d'importance car il fera le même "mal" des deux côtés. Mais s'il s'agit d'un mélange ARC / non-ARC, il y a une discordance.
ARC perdra de la mémoire lors des levées d'exceptions ObjC. Une exception ObjC doit être très proche de la fin de votre programme. Si vous détectez un nombre important d'exceptions ObjC, vous les utilisez de manière incorrecte. Ceci peut être corrigé en utilisant -fobjc-arc-exceptions, mais il encourt les pénalités décrites ci-dessous:
ARC ne perdra pas de mémoire pendant les levées d'exceptions ObjC ou C ++ dans le code ObjC ++, mais cela se fait au détriment des performances en termes de temps et d'espace. Ceci est encore une autre parmi une longue liste de raisons pour minimiser votre utilisation d'ObjC ++.
ARC ne fonctionnera pas du tout sur iPhoneOS 3 ou Mac OS X 10.5 ou version antérieure. (Cela m'empêche d'utiliser ARC dans de nombreux projets.)
__weakles pointeurs ne fonctionnent pas correctement sur iOS 4 ou Mac OS X 10.6, ce qui est dommage, mais assez facile à contourner. __weakLes pointeurs sont excellents, mais ils ne sont pas le principal argument de vente d'ARC.
Pour plus de 95% du code, ARC est génial et il n'y a aucune raison de l'éviter (à condition que vous puissiez gérer les restrictions de version du système d'exploitation). Pour le code non ARC, vous pouvez transmettre -fno-objc-arcfichier par fichier. Xcode rend malheureusement cela beaucoup plus difficile qu'il ne devrait l'être en pratique. Vous devriez probablement déplacer le code non-ARC dans un xcodeproj séparé pour simplifier cela.
En conclusion, passez à ARC dès que vous le pouvez et ne regardez jamais en arrière.
ÉDITER
J'ai vu quelques commentaires du genre "l'utilisation d'ARC ne remplace pas la connaissance des règles de gestion de la mémoire Cocoa." C'est généralement vrai, mais il est important de comprendre pourquoi et pourquoi pas. Premièrement, si tout votre code utilise ARC et que vous enfreignez les trois mots magiquespartout, vous n'aurez toujours aucun problème. Choquant à dire, mais voilà. ARC peut conserver certaines choses que vous ne vouliez pas conserver, mais il les libérera également, donc cela n'aura jamais d'importance. Si j'enseignais une nouvelle classe à Cocoa aujourd'hui, je ne passerais probablement pas plus de cinq minutes sur les règles de gestion de la mémoire, et je ne mentionnerais probablement que les règles de dénomination de la gestion de la mémoire lors de la discussion de la dénomination KVC. Avec ARC, je crois que vous pourriez devenir un programmeur débutant décent sans apprendre du tout les règles de gestion de la mémoire.
Mais vous ne pouvez pas devenir un programmeur intermédiaire décent. Vous devez connaître les règles pour établir correctement le lien avec Core Foundation, et chaque programmeur intermédiaire doit traiter avec CF à un moment donné. Et vous devez connaître les règles du code mixte ARC / MRC. Et vous devez connaître les règles lorsque vous commencez à jouer avec des void*pointeurs id(dont vous continuez à avoir besoin pour exécuter correctement KVO). Et les blocs ... eh bien, la gestion de la mémoire par blocs est juste bizarre.
Donc, mon point est que la gestion de la mémoire sous-jacente est toujours importante, mais là où je passais beaucoup de temps à énoncer et à reformuler les règles pour les nouveaux programmeurs, avec ARC, cela devient un sujet plus avancé. Je préfère amener les nouveaux développeurs à penser en termes de graphes d'objets plutôt que de se remplir la tête avec les appels sous-jacents à objc_retain().