Est-ce que du coup on ne devra plus mettre les lignes du genre @property (nonatomic, retain) / @synthesize / [... release] ?

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 ?

@itralala J'espère, parce que à la longue c'est lourd...

@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.

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.

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.

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

@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 !!

Ç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!

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.

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.

@ liocec : A priori oui en ayant lu la doc développeurs sur leur site...

C'est fou, signer une NDA ne veut plus rien dire aujourd'hui...

@ dperetti : Pareil...

[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.

@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...

Excellente nouvelle !

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 ! ;-)

@ 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.

@ 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.

@ 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.

@ 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.

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.

@ 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).

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/

@ 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...