LLVM passe la troisième avec Xcode 4.2

Nicolas Furno |
Avec Xcode 4.2, distribué pour le moment uniquement en bêta aux développeurs, Apple a mis à jour le compilateur LLVM. Passant en version 3, il remplace le Garbage Collector de Mac OS X et il permet aux développeurs iOS et Mac OS de ne plus se soucier de la gestion manuelle de la mémoire. Renommée Automatic Reference Counting (ARC) par Apple, cette fonction est disponible avec Xcode 4.2 et pour des applications Mac OS X 10.6 et 10.7 ou iOS 4 et 5.

LLVM 3

Sans trop entrer dans les détails techniques, ARC va analyser le code au moment de sa compilation. À chaque fois qu'il l'estime nécessaire, ARC va ajouter du code pour libérer la mémoire utilisée jusque-là par le programme. Cette libération devait jusque-là être effectuée manuellement par le développeur ; grâce à ARC, tout se fera automatiquement au moment de la compilation.

Pour utiliser cette fonction, il faudra convertir les projets à ARC. Xcode va alors retirer les mécanismes manuels de gestion de mémoire pour éviter un conflit avec ses propres mécanismes automatiques. Le code en Objective-C ne sera pas modifié, mais c'est le résultat lui-même (l'application compilée) qui sera modifié pour ajouter les fonctions de gestion de mémoire. Si vous créez un nouveau projet dans Xcode 4.2, ARC sera activé par défaut.

Tags
avatar itralala | 
Est-ce que du coup on ne devra plus mettre les lignes du genre @property (nonatomic, retain) / @synthesize / [... release] ?
avatar iNabil | 
je ne m'y connait pas trop mais je voudrais quand même connaître les avantages par rapport au ramasseur de miettes, si ce n'est que ARC fonctionnera aussi avec iOS ?
avatar Ludavid21 | 
@itralala J'espère, parce que à la longue c'est lourd...
avatar cprail | 
@property et @synthesize sont là pour créer automatiquement des getters et des setters, pas pour la gestion de la mémoire en tant que telle. Nonatomic est là pour le threading. Et je doute qu'on puisse se débarasser de copy/retain/assign comme ceux là dictent la marche à suivre: conserver un pointeur vers un seul et même objet partagé ou en créer un nouveau, etc. Bref on doit imaginer le tout comme si tous nos objets étaient en autorelease.
avatar Mithrandir | 
Il y avait un ramasse miettes avant, mais que pour Mac OS X, l'avantage, c'est que maintenant on n'a plus besoin de se préoccuper de gestion mémoire sur iOS.
avatar rokdun | 
sauf erreur, un ramasse miettes est un truc qui se déclenche de temps en temps et qui parcourt toute la mémoire du programme pour voir s'il y a pas des trucs à libérer, ce qui peut prendre un certain temps. Avec un compteur de références automatique, la libération est immédiate (on sait que quand le compteur est à zéro, on peut libérer tout de suite), donc pas besoin d'un balayage complet de temps en temps.
avatar lilpit | 
Le gros avantage c'est qu'il n'y a pas de perte de performances comme avec le garbage collector car l'ARC n'est pas un runtime en execution avec l'application mais est lancé seulement à la compilation, on cumule donc tous les avantages : simplicité de programation et performances. @ itralala : il faut toujours les @synthesize mais on remplace les asign, alloc par 2 nouveaux mots clés pour la gestion automatique de la memoire : strong et weak
avatar dperetti | 
@cprail : si, si, c'est bien la fin des des retain / release. Autant je n'ai jamais été chaud pour le garbage collection, autant là il faut bien reconnaître qu'il n'y a pas d'argument contre. Ca fait tout bizarre !!
avatar greensource | 
Ça ne parle pas a tous mais oui la c'est vraiment une révolution! Vous n'imaginez pas le temps perdu a debuggué a cause de tout ça. La gestion mémoire était très bien faite mais là, tout automatiser c'est génial!
avatar dperetti | 
Attention ça ne veut pas dire qu'on n'aura plus à réfléchir. La notion de référence continue à exister mais elle est plus pertinente. Il faudra penser en terme de propriétaire de l'objet. En gros, là où on utilisait avant "assign", on utilisera "weak", et le pointeur deviendra nul quand l'objet sera effacé. (comme dans actionscript 3 en fait !) En fait ce qui est génial c'est que c'est la fin de dealloc.
avatar liocec | 
Ce qui est fou, c'est que dans les années 2000, Delphi (IDE Pascal objet sous Windows) faisait déjà ça et très bien, avec un gain de temps considérable par rapport au C++. Donc ça ne peut être que positif. J'espère cependant qu'Apple a prévu un mode "manuel" pour permettre à qui le veut de gérer soi-même la mémoire.
avatar Mithrandir | 
@ liocec : A priori oui en ayant lu la doc développeurs sur leur site...
avatar Vivid (non vérifié) | 
@Greensource automatiser aussi les développeurs, génial !! de moins en moins besoin de compétences et un salaire qui va avec ! ouais génial!
avatar Ali Baba | 
C'est fou, signer une NDA ne veut plus rien dire aujourd'hui...
avatar Ali Baba | 
@ dperetti : Pareil...
avatar ErGo_404 | 
[quote]Vivid [07/06/2011 18:38] @Greensource automatiser aussi les développeurs, génial !! de moins en moins besoin de compétences et un salaire qui va avec ! ouais génial![/quote] C'était inévitable, les informaticiens ont remplacé pas mal de boulots, sans jamais se douter qu'ils allaient se remplacer eux même un jour. Mais en même temps être fier de garder son métier et parler de compétences pour la gestion de la mémoire, c'est stupide, la gestion de mémoire est et a toujours été une perte de temps immense pour beaucoup de développeurs.
avatar rom54 | 
@liocec Certes, mais c'était du Pascal, voir du Clascal, un langage largement en avance par rapport au C++ et en général face aux représentants postérieurs de la famille de C. Un langage, expressif, facile a optimiser et a debugguer, obligeant le programmeur à prendre de bonnes habitudes... Il est aussi amusant de noter que le langage de développement original du Mac (et du Lisa) était Pascal... Version à l'origine de Delphi d'ailleurs... Comme quoi le monopole des bonnes idées que l'on enterre n'est pas detenu par Microsoft! Et dire que l'on pourrait développer en Eiffel, lui aussi disposant d'un GC intelligent... @ErGo_404 Petite maxime dans le monde des developpeurs: "la gestion de la mémoire est trop importante pour laisser le programmeur s'en occuper" tenant des langages dynamique de la famille Lisp "la gestion de la memoire est trop importante pour laisser un logiciel s'en occuper" tenant des langages statique de la famille Pascal hormis le cas ou la machine dispose d'une memoire infinie (et encore) la gestion de la memoire est le coeur de métier du developpeur. Si on ne sait pas structurer ses données, ni prévoir les allocations, c'est que l'on est pas un développeur... Ceci dit programmer en Objective-C avec Cocoa, ressemble de plus en plus à de la programmation Smalltalk donc la gestion automatique de la memoire était une évidence a un moment ou a un autre. D'un autre coté, le fait d'ouvrir le développement sur OS x/iOS en Objective-C à tout le monde implique que de plus en plus de programmes seront ecrit par des personnes n'ayant jamais mis les pieds dans un cours d'info, ni ayant ouvert un bouquin de Wirth, de Tanenbaum ou encore de Meyer... Donc faut bien limiter les dégâts...
avatar Lemmings | 
Excellente nouvelle !
avatar outmen | 
Dommage que le dev iOS ne s'ouvre pas au java, que je préfère largement (et ou on ne se préoccupe pas de la libération mémoire). Mais tout de même, c'était LA nouvelle que j'attendais pour me former a Objective C car faire des releases a la main, franchement c'est chiant, c'est la préhistoire ! ;-)
avatar Mithrandir | 
@ Vivid : Euh si un truc indispensable mais sans valeur ajoutée peut être supprimé, je ne bois pas le problème. Je précise que je suis développe en Java depuis 10 ans environ, et ce n'est pas pacte qu'il h a un Garbage Collector que développer en Java ne demande pas de compétences. Pour prendre un exemple. Et les fuites mémoires, c'est la plaie. Il est certain qu'il y a moins de risque en ObjectiveC qu'en C++, mais le risque est tout de même loin d'être nul.
avatar Mithrandir | 
@ rom54 : Non la gestion de la mémoire est le coeur du métier du développeur pour les langages qui lui laissent tout faire. C'est comme dire que les pointeurs (pas les références) c'est fondamental. C'est fondamental en C et ses dérivés.
avatar Mithrandir | 
@ rom54 : Structurer les données et savoir quand libérer la mémoire sont deux choses différentes. Java a des types de données très fortement structurés, mais un ramasse miettes, d'ailleurs très performant.
avatar Ali Baba | 
@ rom54 : Sympa pour les dev PHP, JavaScript, Perl... Ah mais j'oubliais, ce ne sont pas des vrais développeurs. Les vrais développeurs ils codent en assembleur.
avatar Chamalo | 
Ca va servir a un paquet de mauvais programmeurs qui ne savent pas gerer la memoire. Et il y en a un paquet, meme sur des app de grandes entreprises ... Un bon dev ces gerer la mémoire manuellement. On sait ce qu on fait au moins :) Au passage sur l'app macge mobile, tous les articles sont stockés sur l appareil ?? Pourquoi ca ? J'ai un app de 30mo a synchro sur iCloud la je trouve ca beaucoup.
avatar BeePotato | 
@ outmen : « Dommage que le dev iOS ne s'ouvre pas au java » Berk ! Non, franchement, utiliser un framework comme Cocoa (ou plutôt, ici, Cocoa Touch) en Java, c’est nettement moins confortable. Il a été pensé pour l’Objective C, point. « Mais tout de même, c'était LA nouvelle que j'attendais pour me former a Objective C car faire des releases a la main, franchement c'est chiant, c'est la préhistoire ! ;-) » Ce n’est pas la préhistoire. Plutôt l’antiquité. La préhistoire, c’est la gestion de la mémoire sans comptage de références. Le comptage de références, ça amène tout de même un énorme confort (et ça réduit énormément le risque de bugs).
avatar BeePotato | 
Au fait… @ Ali Baba : « C'est fou, signer une NDA ne veut plus rien dire aujourd'hui... » Cette information est publique : http://developer.apple.com/technologies/ios5/
avatar liocec | 
@ Chamalo : C'est totalement faux : si un "bon dev sait gérer la mémoire"... alors allons plus loin, un bon dev doit savoir programmer en assembleur hexa (sans mnémonique) ! Non, non, non... Je rigole Un bon dev est celui qui utilise correctement son outil de développement, qui code sans bug, sans lourdeur, etc... S'il sait gérer la mémoire c'est un plus. Mais si pour toi revenir à l'âge de pierre c'est bien, alors libre à toi...
avatar Vivid (non vérifié) | 
pour moi c'est un tout est surtout un plaisir que de faire travailler ces neurones en programmation. @BeePotato; le confort cela amène à en faire de moins en moins :-) et laisser le cerveau au vestiaire. Alors une phrase que j'aime bien ; À vaincre sans péril, on triomphe sans gloire, à remplacé gloire par plaisir.

CONNEXION UTILISATEUR