Automatic Reference Counting (ARC)

Paisible.frPaisible.fr Membre
03:13 modifié dans Actualités #1
MacGeneration vient de publier un article intitule LLVM passe la troisième avec Xcode 4.2

On y parle nottament de la technologie ARC (Automatic Reference Counting) qui permettra aux développeurs iOS et Mac OS de ne plus se soucier de la gestion manuelle de la mémoire.

Qu'en pensez-vous ?
Cela m'a l'air fort interressant et prometteur.
«1

Réponses

  • muqaddarmuqaddar Administrateur
    03:13 modifié #2
    Gnnn ?
    Mais je sais plus écrire du code sans gérer la mémoire moi !  ;D

    Va falloir tester tout ça, l'efficacité et les perfs bien sûr.
  • SmySmy Membre
    03:13 modifié #3
    Gnnn !

    J'aime bien gérer ma mémoire tout seul, moi :)

    (bon, j'aime bien l'autorelease tout de même)
  • Paisible.frPaisible.fr Membre
    03:13 modifié #4
    Oh rassurez-vous, je n'en ai pas la preuve, mais je suis pret a parier que ce sera une option ou un parametre et que chacun pourra faire comme bon lui semblera.
  • AliGatorAliGator Membre, Modérateur
    03:13 modifié #5
    Oui pareil j'aurais du mal à  ne plus gérer la mémoire moi-même moi !!
    Ca va me perturber ^^
  • DrakenDraken Membre
    03:13 modifié #6
    Si c'est efficace, j'adopte TOUT DE SUITE ! La gestion mémoire, c'est le Mal !

  • SmySmy Membre
    03:13 modifié #7
    dans 1307458115:

    Si c'est efficace, j'adopte TOUT DE SUITE ! La gestion mémoire, c'est le Mal !


    Remplace ta signature par "Moi je suis Garbage Collector, et vous ?"
  • DrakenDraken Membre
    juin 2011 modifié #8
    Nan, toi pas comprendre, pas être Garbage Collector, mais bonne vieille gestion mémoire automatisée ! Toi trop fatigué par chasse aux spectres, revenants, vampires, loups-garous, sorciers, nécromants et mutants ?

    J'y pense subitement, ça existe un détecteur de mutants sous iOS ? C'est d'actualité avec la sortie du dernier film X-Men.

  • SmySmy Membre
    03:13 modifié #9
    Attention Draken, nous allons (encore) partir dans des digressions et pourrir ce sujet ;) Nous en sommes capables tous les deux...

    Donc je ne réponds pas, enfin pas trop.
  • DrakenDraken Membre
    juin 2011 modifié #10
    * écarte négligemment Smy *

    Si l'ARC résout efficacement les problèmes de gestion mémoire, c'est tout bon pour les développeurs formés aux langages classiques avec Garbage Collector. C'est un verrou de plus qui saute pour les novices.

  • Eddy58Eddy58 Membre
    03:13 modifié #11
    Ce serait apparemment en option à  la création du projet.... option que je décocherais pour ma part.
  • AliGatorAliGator Membre, Modérateur
    03:13 modifié #12
    dans 1307462942:

    * écarte négligemment Smy *

    Si l'ARC résout efficacement les problèmes de gestion mémoire, c'est tout bon pour les développeurs formés aux langages classiques avec Garbage Collector. C'est un verrou de plus qui saute pour les novices.
    C'est bien ce qui me fait peur.
    Bonjour les architectures bien brouillon et les codes grand n'importe quoi sans réflection préalable sur l'archi logicielle du code...
  • 03:13 modifié #13
    dans 1307462942:

    * écarte négligemment Smy *

    Si l'ARC résout efficacement les problèmes de gestion mémoire, c'est tout bon pour les développeurs formés aux langages classiques avec Garbage Collector. C'est un verrou de plus qui saute pour les novices.


    Malheureusement..
  • DrakenDraken Membre
    03:13 modifié #14
    Un volontaire pour écrire un ouvrage de référence sur les bonnes pratiques. J'ai déjà  le titre: "AliPédia pour les Nuls"  ::)

  • CeetixCeetix Membre
    03:13 modifié #15
    J'ai déjà  vu des commentaire sur la toile du genre "ca veut dire qu'on aura plus besoin d'écrire @property @synthetize";
    C'est triste ...

    Ca me plait pourtant bien de manager moi-même ce que je fais en allocation et libération. On comprends mieux comment le bouzin fonctionne et si on le fait bien c'est carrément plus performant que de foutre un garbage collector.
  • Eddy58Eddy58 Membre
    03:13 modifié #16
    dans 1307469220:

    Ca me plait pourtant bien de manager moi-même ce que je fais en allocation et libération. On comprends mieux comment le bouzin fonctionne et si on le fait bien c'est carrément plus performant que de foutre un garbage collector.

    +1, ça donne une grande partie de son sens au mot "Programmation". Personnellement je n'aurais pas l'impression de tout maitriser et je me demanderais si vraiment tout a été optimisé pour que tout tourne au mieux, surtout dans du code devenant complexe. Remarque quand à  l'occasion je fais du VB ou Java je ne me pose pas cette question vu que ces langages tournent naturellement avec un GC.... mais Cocoa c'est pas pareil il permet justement de bien maitriser la gestion mémoire donc il serait bête de s'en priver.
  • zoczoc Membre
    03:13 modifié #17
    ARC n'est pas un garbage collector.
  • Eddy58Eddy58 Membre
    03:13 modifié #18
    Non, mais par principe le résultat final pour le développeur est le même : Ne plus avoir à  s'occuper de la gestion mémoire.
  • DrakenDraken Membre
    03:13 modifié #19
    Non, le résultat final pour le développeur n'est pas le même. L'utilisation d'un Garbage Collector diminue les performances d'une application, alors que l'ARC devrait arriver à  la même efficacité qu'une gestion manuelle de la mémoire.

  • 03:13 modifié #20
    dans 1307480725:

    Non, le résultat final pour le développeur n'est pas le même. L'utilisation d'un Garbage Collector diminue les performances d'une application, alors que l'ARC devrait arriver à  la même efficacité qu'une gestion manuelle de la mémoire.

    Il est même dit que c'est mieux que la gestion manuelle
  • Eddy58Eddy58 Membre
    juin 2011 modifié #21
    dans 1307480725:

    Non, le résultat final pour le développeur n'est pas le même. L'utilisation d'un Garbage Collector diminue les performances d'une application, alors que l'ARC DEVRAIT arriver à  la même efficacité qu'une gestion manuelle de la mémoire.


    Je n'aime pas trop le conditionnel.... surtout dans un domaine qui demande quand même de la rigueur. Ensuite je ne suis pas contre, mais tout de même dubitatif dans des cas d'optimisations extrême. Une mauvaise gestion mémoire peu autant (voir plus) plomber les performances d'une application qu'un Garbage Collector.
  • AliGatorAliGator Membre, Modérateur
    03:13 modifié #22
    Moi j'aurais bien aimé un mode assisté plutôt qu'un mode automatique.

    Je veux dire que si LLVM est capable de savoir quand je devrais faire un retain et quand je devrais faire un release, je préférerais qu'il vérifie que dans mon code je les ai mis, et me mette des warnings là  où j'aurai pu en oublier pour m'inciter à  en rajouter... plutôt qu'il les rajoute lui-même tout seul dans le binaire compilé sans me dire où il les as mis.

    Ca serait à  la fois plus pédagogique et plus efficace permettant de toujours tout gérer moi-même tout en étant sûr de ne rien oublier.
  • zoczoc Membre
    03:13 modifié #23
    Bin c'est ce que fait déjà  l'analyse statique du code, non ?

  • AliGatorAliGator Membre, Modérateur
    03:13 modifié #24
    Oui et non, l'analyze statique ne va pas assez loin, du moins pas avec la version de LLVM fournie avec Xcode.

    En particulier, elle remonte les variables sur lesquelles il y a eu un retain mais pas de release, mais que pour les variables locales. Elle ne remonte pas ce manque de "release" si c'est une ivar (pour laquelle typiquement on fait un retain dans une méthode et un release dans une autre ou dans le dealloc)
    En particuleir, elle ne remonte pas, également, les variables à  qui on devrait envoyer un retain -- parce qu'elles sont utilisées plus tard -- mais que l'on a pas fait.

    Il me semble que pourtant LLVM est capable de faire cela... mais il faut récupérer le code source de LLVM et le recompiler avec les flags qui vont bien pour qu'il soit aussi pointilleux (du moins c'est ce qu'on m'a dit) ; avec la version de LLVM (enfin du module clang de LLVM) fourni avec Xcode ce n'est pas le cas et du coup l'analyse statique n'est pas utilisée au maximum.
  • DrakenDraken Membre
    03:13 modifié #25
    Mon premier essai avec ARC et iOS 5, sur mon iPhone 4: une petite application permettant d'afficher et de déplacer des sprites avec le doigt. Quelques lignes de code et ça marche.  :)

  • NseaProtectorNseaProtector Membre
    03:13 modifié #26
    A ce que je vois, il y'avait un vrai besoin d'en parler ! Ca fait du bien, non ? LOL
    Sinon, concrètement c'est juste une option a cocher ?
    Cela autorise quelle liberté ?
  • muqaddarmuqaddar Administrateur
    03:13 modifié #27
    dans 1309289768:

    Mon premier essai avec ARC et iOS 5, sur mon iPhone 4: une petite application permettant d'afficher et de déplacer des sprites avec le doigt. Quelques lignes de code et ça marche.  :)


    Bah, avec ta capture, on voit pas trop le rapport avec Arc !  :P

    (hors sujet)
    Bon, sinon, au lieu de faire de la veille techno, quand c'est que tu nous montres une production maison ?  >:)
  • DrakenDraken Membre
    03:13 modifié #28
    Tant que le NDA n'est pas levé, je ne peux pas montrer le code source, juste le résultat. Et comme j'aime les jeux vidéos, une gestion de sprites est un bon sujet pour tester la nouvelle manière de développer.

    Pour le reste, attend fin Septembre/début Octobre * croise les doigts *

  • DrakenDraken Membre
    03:13 modifié #29
    dans 1309292351:

    A ce que je vois, il y'avait un vrai besoin d'en parler ! Ca fait du bien, non ? LOL

    Pour le moment c'est un peu difficile d'en parler à  cause du NDA.

    dans 1309292351:

    Sinon, concrètement c'est juste une option a cocher ?

    Même pas, ça marche de base. Je présume qu'il doit y avoir quelque part une option à  cocher pour désactiver ARC.

    dans 1309292351:

    Cela autorise quelle liberté ?

    Exit les retain et release dans le code. Plus besoin de dealloc. Merci mon dieu !  :)

  • NseaProtectorNseaProtector Membre
    03:13 modifié #30
    La NDA ? C'est open source ! Et la doc est en ligne : http://clang.llvm.org/docs/AutomaticReferenceCounting.html
  • DrakenDraken Membre
    03:13 modifié #31
    Cool ! Alors on peut en parler. Tu en penses quoi, toi ?

Connectez-vous ou Inscrivez-vous pour répondre.