›

Le point sur ARC

MalaMala Membre, Modérateur
octobre 2012 modifié dans Objective-C, Swift, C, C++ #1
Après le garbage collector d'Objective-C qui a fait un flop et pour cause... Je me pose la question de l'avenir d'ARC. Réelle amélioration ou nouvel argument commercial destiné aux nouveaux venus?



J'aimerais bien avoir l'opinion de ceux qui l'on déjà  mis en oeuvre au jour le jour. Je m'attendais à  ce que cela soit relativement transparent mais cela n'a pas l'air aussi simple que ça dans les faits. Je suis preneur de vos opinons.
Mots clés:
«13

Réponses

  • Alf1996Alf1996 Membre
    #2
    Perso, je n'utilise pas ARC, bien qu'étant plutôt novice... Je me suis habituée à  la gestion mémoire, et j'ai plutôt tendance à  faire du "conservatisme" (idem pour le storyboard...).

    A mon avis, çà  peut attirer les nouveaux venus dans un premier temps car çà  rend le code plus "accessible", mais c'est dommage... La compréhension de la gestion mémoire reste, à  mon avis, quelque chose de primordial...
  • KixxxKixxx Membre
    #3
    'Alf1996' a écrit:


    Perso, je n'utilise pas ARC, bien qu'étant plutôt novice... Je me suis habituée à  la gestion mémoire, et j'ai plutôt tendance à  faire du "conservatisme" (idem pour le storyboard...).

    A mon avis, çà  peut attirer les nouveaux venus dans un premier temps car çà  rend le code plus "accessible", mais c'est dommage... La compréhension de la gestion mémoire reste, à  mon avis, quelque chose de primordial...


    Idem
  • CeetixCeetix Membre
    #4
    On ne peut pas vraiment comparer ARC à  un Garbage Collecteur. ARC si j'ai bien compris s'occupe de foutre tout seul comme un grand les release quand il juge que ce sera nécessaire à  ce moment.

    Je ne l'utilise pas en tout cas.
  • MonsieurPaulMonsieurPaul Membre
    #5
    Au risque de me faire taper dessus, je suis bien content qu'il y ait quelque chose comme l'ARC, parce que la gestion de la mémoire c'est pas mal de la magie noire en ce qui me concerne.
  • CeetixCeetix Membre
    #6
    C'est bien dommage ...

    J'imagine même pas si un jour tu vas devoir gérer du C++ ou pire, du C. Tu vas être dans le caca ^^
  • tabliertablier Membre
    #7
    Je n'utilise pas non plus, même si parfois j'ai besoin d'une piqure de rappel sur la gestion de la mémoire.
  • MalaMala Membre, Modérateur
    #8
    'MonsieurPaul' a écrit:


    Au risque de me faire taper dessus, je suis bien content qu'il y ait quelque chose comme l'ARC, parce que la gestion de la mémoire c'est pas mal de la magie noire en ce qui me concerne.


    Pas de risque. On est non violant ici...

    image/cliccool.gif' class='bbc_emoticon' alt=' :p ' /> image/cliccool.gif' class='bbc_emoticon' alt=' :p ' /> image/cliccool.gif' class='bbc_emoticon' alt=' :p ' />



    Quand je compare ARC au GB, c'est bien évidement de la provocation. J'ai conscience qu'ARC est plus évolué.
  • SystemSystem
    #9
    Le fait que la gestion mémoire manuelle puisse paraà®tre comme étant de la magie noire n'est pas la raison de l'existence d'ARC.

    D'une part, ARC n'a vraiment rien à  voir avec le Garbage Collector, puisque c'est le compilateur qui s'occupe de "deviner" où placer les release, alors que le Garbage Collector s'occupe (corrigez-moi si je me trompe) de faire un nettoyage d'objets non utilisés en temps réel (cà d pendant que l'application tourne). Grosse différence donc... fini les pertes de perfs ainsi que des plantages plus qu'exotiques.



    ARC existe car, dixit Apple, "La première cause de plantage d'une application OS X / iOS vient d'un problème au niveau de la gestion mémoire".

    ARC, ça a l'air vraiment pas mal et puissant. Mais je le dis et insiste énormément dessus: n'utilisez pas ARC si vous êtes un débutant. Il vous faut absolument maà®triser la gestion mémoire avant de vous attaquer à  ARC. ça peut vous paraà®tre stupide dit comme ça, mais utiliser un langage orienté-objet sans même connaà®tre les mécanismes de base de la gestion mémoire ne fera que vous handicaper à  un moment ou un autre, même avec ARC activé.



    Pour ma part, je ne m'y suis toujours pas mis simplement car je trouve ça assez déroutant.
  • MalaMala Membre, Modérateur
    #10
    Un framework compilé en ARC peut-il être utilisé dans un projet non ARC?
  • ThibautThibaut Membre
    #11
    Oui. Pour chaque fichier d'un projet, on peut spécifier si l'on utilise ARC ou non.
  • MalaMala Membre, Modérateur
    #12
    'Thibaut' a écrit:


    Oui. Pour chaque fichier d'un projet, on peut spécifier si l'on utilise ARC ou non.


    Intéressant. C'était une grosse limite du GC il me semble.
  • MonsieurPaulMonsieurPaul Membre
    #13
    'ldesroziers' a écrit:
    Mais je le dis et insiste énormément dessus: n'utilisez pas ARC si vous êtes un débutant. Il vous faut absolument maà®triser la gestion mémoire avant de vous attaquer à  ARC.




    De toute façon, pour utiliser ARC on est un peu obligé de connaà®tre les bases de la gestion mémoire, ne serait-ce que pour les strong vs weak references.
  • zoczoc Membre
    mars 2012 modifié #14
    'Mala' a écrit:


    J'aimerais bien avoir l'opinion de ceux qui l'on déjà  mis en oeuvre au jour le jour. Je m'attendais à  ce que cela soit relativement transparent mais cela n'a pas l'air aussi simple que ça dans les faits. Je suis preneur de vos opinons.


    Dans les faits, si, c'est relativement transparent. Alors que sans ARC il faut réfléchir à  la gestion mémoire pratiquement à  chaque ligne de code écrite, avec ARC, cela devient une exception, le cas général étant très bien géré par le compilateur.



    Les exceptions principales:
    • Les casts de pointeurs sur objets vers/depuis un pointeur "void *", pour lesquels ils faut préciser à  ARC de passer d'un mode où il gère vers un mode où il ne gère pas (ou inversement) la mémoire. Pour cela, on utilise un "bridged cast" (mot clé __bridge). Exemple void *foo = (__bridge void *)[NSNumber numberWithInt:10];
    • Le toll-free bridging entre Core Foundation et l'équivalent Cocoa (exemple CFString et NSString), pour lesquels il faut, encore une fois, utiliser un cast signalant le transfert de gestion mémoire entre ARC et Core Foundation (mots clés __bridge_transfer et __bridge_retained).
    • Les pointeurs pour lesquels on ne veut pas générer d'appels à  retain/release (par exemple les delegates) pour éviter les "retain cycles" (que ARC ne résoud pas) doivent être marqués __weak (iOS >= 5.0 et MacOS X >= 10.7) ou __unsafe_unretained (pour les versions précédentes).


    C'est à  peu près tout. Donc si vous n'utilisez pas le toll-free bridging ni ne castez vos pointeurs dans tous les sens, ARC est indolore et totalement silencieux pour vous.



    Il faut bien comprendre que ARC et GC sont fondamentalement différents. Là  où GC traque les objets orphelins (c'est à  dire les objets qui ne sont plus accessibles par un pointeur) à  l'aide d'un runtime complexe qui nécessite l'exécution de code en tâche de fond (thread du GC), ARC se contente de rajouter des appels à  retain/release/autorelease au moment de la compilation du code, là  où vous les auriez rajoutés si vous aviez géré la mémoire vous même.



    Les avantages sont multiples: Pas de runtime supplémentaire, compatibilité totale entre le code ARC et le code non ARC (tant qu'il respecte les conventions de nommage), et, comme le dit Greg Parker (qui est le chef de projet du runtime objective-c chez Apple), le compilateur est meilleur que vous pour placer les appels de gestion mémoire aux endroits optimums.
  • KubernanKubernan Membre
    #15
    Je me suis mis à  l'ARC qui comme indiqué plus haut n'est pas du Garbage Collector.



    À vrai dire je n'ai pas de préférences quant à  l'usage ou non de l'ARC. L'usage de l'ARC allège le code en tout cas et - parait-il - c'est plus performant (pas fait de test en ce sens).



    En même temps je ne me vois pas rejeter toute amélioration qui va dans le bon sens. C'est ainsi que j'ai adopté Storyboard également.

    Concernant la simplicité de mise en oeuvre de l'ARC... je ne peux y répondre car je l'utilise sur un nouveau projet (pas de refactoring).



    Enfin, peu importe qu'un débutant soit attiré par l'ARC. Celui qui ne veut pas faire d'effort fera toujours un résultat pourri. Avec ou sans ARC.
  • zoczoc Membre
    mars 2012 modifié #16
    Pour compléter mon message: Un autre avantage de ARC, c'est que si vous vous trouvez dans une des exceptions de gestion mémoire et que vous ne faites rien, le compilateur ne sera pas quoi faire et génèrera une erreur, jusqu'à  ce que vous précisiez ce que votre code fait (à  l'aide des mots clés que j'ai cités).



    Quand on utilise pas ARC, tout écart dans la gestion mémoire (oubli de release/retain, release en trop, etc...) est indétectable par le compilateur (oui, je sais, il y a l'analyse syntaxique, mais elle a ses failles), et c'est au développeur de traquer les bugs à  l'exécution.



    En ce qui me concerne, je n'écrirai plus de code en gérant la mémoire manuellement. ARC le fait très bien et est clairement la solution d'avenir (les avantages du Garbage Collector sans ses inconvénients, avec un investissement minimum)
  • JegnuXJegnuX Membre
    #17
    Pour mon prochain projet au boulot, je pense qu'on va tenter l'expérience ARC.

    Mais ça va m'énerver de pas pouvoir mettre des NSLog (ou breakpoint symbolique) sur les dealloc pour vérifier rapidement si mes objets sont bien détruit quand je le veux ^^
  • MalaMala Membre, Modérateur
    mars 2012 modifié #18
    'JegnuX' a écrit:
    Mais ça va m'énerver de pas pouvoir mettre des NSLog (ou breakpoint symbolique) sur les dealloc pour vérifier rapidement si mes objets sont bien détruit quand je le veux ^^


    Moi j'avais fait bien mieux... image/grin.gif' class='bbc_emoticon' alt=';D' />

    http://www.sam.eliot...oryWatchDog.mov
  • JegnuXJegnuX Membre
    #19
    'Mala' a écrit:


    Moi j'avais fait bien mieux... image/grin.gif' class='bbc_emoticon' alt=';D' />

    http://www.sam.eliot...oryWatchDog.mov




    J'avoue. Derrière ça fonctionne comment ? runtime ?
  • CéroceCéroce Membre, Modérateur
    #20
    Je rejoins les avis de zoc et Louka: ARC fait gagner du temps de développement, et évite 80% des plantages, qui sont liés à  une mauvaise gestion mémoire.



    Toutefois, pendant les formation Mediabox, je force les stagiaires à  apprendre la gestion de la mémoire; de mon point de vue, ARC n'est pas magique, et il faut tout de même qu'ils fassent la différence entre un [[NSString alloc] initWithFormat:] et un [NSString stringWithFormat:].
  • zoczoc Membre
    mars 2012 modifié #21
    'JegnuX' a écrit:


    Pour mon prochain projet au boulot, je pense qu'on va tenter l'expérience ARC.

    Mais ça va m'énerver de pas pouvoir mettre des NSLog (ou breakpoint symbolique) sur les dealloc pour vérifier rapidement si mes objets sont bien détruit quand je le veux ^^


    ARC n'interdit pas d'implémenter une méthode dealloc... La seule différence, c'est que l'implémentation de la méthode:
    • Ne doit pas appeler [super dealloc]
    • Ne doit pas envoyer de release sur les variables d'instance de type objet (c'est ARC qui s'en occupe).


    Donc, clairement, rien n'empêche d'implémenter un dealloc qui fait un NSLog.
  • MalaMala Membre, Modérateur
    #22
    Donc globalement des retours plutôt très positifs sur ARC. Et question rétro compatibilité avec les anciens OS. Il y a des contraintes à  prendre en compte?



    'JegnuX' a écrit:


    J'avoue. Derrière ça fonctionne comment ? runtime ?


    Oui, j'utilise le runtime pour court-circuiter les appels à  init/dealloc/retain/release et les remplacer par mes méthodes de trace. Ensuite, je rappelle ni vu ni connu les méthodes originelles. Certaines applications sur lesquels je travaille doivent fonctionner 24h/24 7J/7 donc hors de question de laisser passer le moindre leak surtout pour les ressources graphiques. Avec un collègue, on a même poussé le vice jusqu'à  historiser les piles d'appel et utiliser la commande atos pour remonter jusqu'au code source...

    http://sam.eliotis.c...oryWatchDog.mov



    Tu as aussi cette catégorie que j'avais présenté il y a pas mal de temps et qui a fait ses preuves...

    Surveiller ses dealloc
  • SmySmy Membre
    #23
    Je n'utilise pas ARC non plus, je préfère gérer à  la main la mémoire comme je l'ai toujours fait en C... Mais c'est peut être très old school.
  • RocouRocou Membre
    #24
    Je suis super content d'ARC. Fini cette stupide gestion de la mémoire image/clap.gif' class='bbc_emoticon' alt=' :D ' />
  • cyranocyrano Membre
    #25
    'zoc' a écrit:




    Ne doit pas appeler [super dealloc]






    ah bon et pourquoi pas ?
  • MalaMala Membre, Modérateur
    #26
    'Rocou' a écrit:


    Je suis super content d'ARC. Fini cette stupide gestion de la mémoire image/clap.gif' class='bbc_emoticon' alt=' :D ' />


    N'est ce pas là  un raccourci dangereux? ARC limite les risques mais ne t'empêche en aucun cas de faire de nombreuses fuites.



    Un simple NSTimer est un bon exemple. Instancié par une classe, si le target est la classe elle même, le NSTimer fait un retain sur le target, on se retrouve pas plus avancé avec ARC. Si on invalide pas le timer à  un moment donné, la classe l'utilisant ne sera jamais libérée même si on ne l'utilise plus...
  • zoczoc Membre
    #27
    'cyrano' a écrit:


    ah bon et pourquoi pas ?


    Parce que de toute façon cela produit une erreur à  la compilation image/kiss.gif' class='bbc_emoticon' alt=':-*' />



    ARC se charge tout seul de faire le [super dealloc] à  la place du développeur.
  • JegnuXJegnuX Membre
    #28
    'zoc' a écrit:


    ARC n'interdit pas d'implémenter une méthode dealloc... La seule différence, c'est que l'implémentation de la méthode:
    • Ne doit pas appeler [super dealloc]
    • Ne doit pas envoyer de release sur les variables d'instance de type objet (c'est ARC qui s'en occupe).


    Donc, clairement, rien n'empêche d'implémenter un dealloc qui fait un NSLog.




    D'accord, je croyais qu'on devait tout simplement pas l'implémenter. Merci pour l'info.
  • cyranocyrano Membre
    #29
    'zoc' a écrit:


    ARC se charge tout seul de faire le [super dealloc] à  la place du développeur.




    merci pour l'info
  • TofTof Membre
    mars 2012 modifié #30
    ça m'a pris un certain temps avant de m'habituer à  la gestion de la mémoire avec Objective C. Mais maintenant c'est devenu un automatisme. Avec du recul je trouve que ce qu'a fait Apple est vraiment bien pensé. Je vois pas vraiment l'intéret de l'ARC. D'autant plus que c'est pas complétement transparent et qu'on peut avoir des surprises avec. Autant dans ce cas là  garder le contrôle de la gestion de la mémoire. C'est d'autant plus important pour les applications développées pour iPhone et iPad.
  • KubernanKubernan Membre
    #31
    'Tof' a écrit:


    ça m'a pris un certain temps avant de m'habituer à  la gestion de la mémoire avec Objective C. Mais maintenant c'est devenu un automatisme. Avec du recul je trouve que ce qu'a fait Apple est vraiment bien pensé. Je vois pas vraiment l'intéret de l'ARC. D'autant plus que c'est pas complétement transparent et qu'on peut avoir des surprises avec. Autant dans ce cas là  garder le contrôle de la gestion de la mémoire. C'est d'autant plus important pour les applications développées pour iPhone et iPad.




    Il y a des règles pour la gestion mémoire sans ARC, il y en a aussi avec l'ARC. Faut juste les adopter, comme tu as pu adopter les retain/release.

    Enfin, je ne vois pas en quoi c'est plus important de ne pas utiliser l'ARC sur iphone... là  ça m'échappe. Au contraire : Apple annonce des performances jusqu'à  2,5 fois plus rapide que les retain/release. C'est plutôt pas mal pour du code sur iPhone.
Connectez-vous ou Inscrivez-vous pour répondre.