En effet, il n'y a pas le même niveau d'abstraction par rapport au formes de GC les plus communes.
Mais, tous les GC ne sont pas globaux, il y a beaucoup de cas où le GC ne gère qu'une partie de la mémoire, et dans ces cas là, l'utilisation ressemble énormément au smart pointers.
Un premier exemple : j'ai bossé avec un DSL où la majorité des types sont atomiques et les objets sont par défaut non-managés et utilisés par référence. Lorsque tu n'as plus besoin d'un objet tu fais un "delete(monobjet)" dessus et la référence deviens un atome représentant un pointeur invalide.
Ce DSL possède en plus un GC utilisé principalement pour les objets qui ont une longue durée de vie où qui passent d'un thread à l'autre. Dans ce cas, tu fais un appel "gc.manage(monobjet)" et tu n'as plus besoin de t'occuper du "delete(monobjet)".
On a bien un GC, de type mark-and-sweep dans ce cas là, qui s'utilise comme un smart pointer et c'est relativement courant comme système.
Deuxième exemple : Le Boehm-GC est un GC pour le C de type mark-and-sweep lui aussi et qui lui aussi ne va manager que la mémoire que tu lui demandes de manager.
Le cas d'utilisation typique c'est, si tu dois allouer de grosses quantités de mémoire qui ne peuvent contenir de références et dont la durée de vie correspond à celle du programme. C'est loin d'être un cas rare : une base de donnée en lecture seule, ou un modèle pour du calcul numérique. Dans ce cas, tu ne manage pas cette mémoire car sa durée de vie est bien connue et tu ne veux pas que le GC perde du temps à scanner cette mémoire à la recherche de référence qui n'y seront pas.
Il n'y a que dans les langages qui intègrent complètement le GC et où tous les objets sont managés que le GC est vraiment plus abstrait que le smart_pointer. En quantité de code qui tourne, ça représente largement la majorité rien qu'avec Java et la majorité des langages de script. Par contre en nombre d'implémentation de GC, je ne suis pas sur que ce soit le cas le plus courant.
Au final un long thread juste à cause d'une correction d'une petite erreur...
[^] # Re: templates variadiques
Posté par beagf . En réponse à la dépêche Le standard C++0x a enfin été voté. Évalué à 3.
En effet, il n'y a pas le même niveau d'abstraction par rapport au formes de GC les plus communes.
Mais, tous les GC ne sont pas globaux, il y a beaucoup de cas où le GC ne gère qu'une partie de la mémoire, et dans ces cas là, l'utilisation ressemble énormément au smart pointers.
Un premier exemple : j'ai bossé avec un DSL où la majorité des types sont atomiques et les objets sont par défaut non-managés et utilisés par référence. Lorsque tu n'as plus besoin d'un objet tu fais un "delete(monobjet)" dessus et la référence deviens un atome représentant un pointeur invalide.
Ce DSL possède en plus un GC utilisé principalement pour les objets qui ont une longue durée de vie où qui passent d'un thread à l'autre. Dans ce cas, tu fais un appel "gc.manage(monobjet)" et tu n'as plus besoin de t'occuper du "delete(monobjet)".
On a bien un GC, de type mark-and-sweep dans ce cas là, qui s'utilise comme un smart pointer et c'est relativement courant comme système.
Deuxième exemple : Le Boehm-GC est un GC pour le C de type mark-and-sweep lui aussi et qui lui aussi ne va manager que la mémoire que tu lui demandes de manager.
Le cas d'utilisation typique c'est, si tu dois allouer de grosses quantités de mémoire qui ne peuvent contenir de références et dont la durée de vie correspond à celle du programme. C'est loin d'être un cas rare : une base de donnée en lecture seule, ou un modèle pour du calcul numérique. Dans ce cas, tu ne manage pas cette mémoire car sa durée de vie est bien connue et tu ne veux pas que le GC perde du temps à scanner cette mémoire à la recherche de référence qui n'y seront pas.
Il n'y a que dans les langages qui intègrent complètement le GC et où tous les objets sont managés que le GC est vraiment plus abstrait que le smart_pointer. En quantité de code qui tourne, ça représente largement la majorité rien qu'avec Java et la majorité des langages de script. Par contre en nombre d'implémentation de GC, je ne suis pas sur que ce soit le cas le plus courant.
Au final un long thread juste à cause d'une correction d'une petite erreur...