Quelle est la différence réelle avec un shared pointeur ? (ormis le fait de devoir écrire shared_pointeur).
Le concept de shared_ptr ne serait pas applicable en ObjC, notamment parce que le langage ne permet pas d’allouer des objets sur la pile (uniquement sur le tas, comme en Java). Donc forcément, ça marche un peu différemment… En Objective-C, la gestion de la mémoire se fait à l’aide d’un compteur de référence (intégré aux objets), qui était jusqu’ici géré manuellement par les développeurs, et qui maintenant est géré automatiquement par ARC (en gros ARC fait le travail des développeurs en rajoutant des appels aux méthodes de gestion du compteur de référence là où c’est nécessaire)
La compatibilité d’un code compilé avec ARC avec du code "classique" est complète (sous réserve que le code classique en question gère correctement la mémoire…), donc ça facilite les migrations (on peut même le faire fichier par fichier). Alors que pour passer d’un code C++ qui fait des new/delete à des shared_ptr, il doit falloir plus de boulot d’un coup…
Je pense aussi que ARC doit pouvoir gérer la mémoire plus finement que les shared_ptr, parce que C++ impose que les objets alloués sur la pile soient détruits seulement lorsqu’il ne sont plus accessibles (donc généralement à la fin de la méthode/fonction). Donc si un objet temporaire est alloué via un shared_ptr au début d’une fonction, il ne sera libéré qu’à la fin, même si il ne sert à rien entre-temps. ARC, en revanche, peut décrémenter le compteur de référence d’un objet dès qu’il n’est plus utilisé.
[^] # Re: il manque une fonctionnalité inutile en c++, le ramasseur de miette
Posté par VinDuv . En réponse au journal C++11 : sur le fil. Évalué à 3.
Le concept de shared_ptr ne serait pas applicable en ObjC, notamment parce que le langage ne permet pas d’allouer des objets sur la pile (uniquement sur le tas, comme en Java). Donc forcément, ça marche un peu différemment… En Objective-C, la gestion de la mémoire se fait à l’aide d’un compteur de référence (intégré aux objets), qui était jusqu’ici géré manuellement par les développeurs, et qui maintenant est géré automatiquement par ARC (en gros ARC fait le travail des développeurs en rajoutant des appels aux méthodes de gestion du compteur de référence là où c’est nécessaire)
La compatibilité d’un code compilé avec ARC avec du code "classique" est complète (sous réserve que le code classique en question gère correctement la mémoire…), donc ça facilite les migrations (on peut même le faire fichier par fichier). Alors que pour passer d’un code C++ qui fait des new/delete à des shared_ptr, il doit falloir plus de boulot d’un coup…
Je pense aussi que ARC doit pouvoir gérer la mémoire plus finement que les shared_ptr, parce que C++ impose que les objets alloués sur la pile soient détruits seulement lorsqu’il ne sont plus accessibles (donc généralement à la fin de la méthode/fonction). Donc si un objet temporaire est alloué via un shared_ptr au début d’une fonction, il ne sera libéré qu’à la fin, même si il ne sert à rien entre-temps. ARC, en revanche, peut décrémenter le compteur de référence d’un objet dès qu’il n’est plus utilisé.