Mais là tu parles de garbage collector (dont une des implémentation est le compteur de références qui est mis en oeuvre dans les smartpointers C++)
Le garbage collector est utilisé uniquement pour les allocations dynamiques (si une allocation a lieu sur la stack, on sait que sa durée de vie est liée à l'appel de fonction l'ayant créé, donc pas besoin de check à la runtime pour savoir quand la libérer).
Le RAII est un concept orthogonal au garbage collector: si ton smartpointer est capable de décrémenter le compteur de référence et de faire la libération de mémoire quand celui-ci arrive à zéro, c'est bien que du code a été appelé automatiquement quand la variable contenant le smarpointer a été détruite. Et cela quelque soit l'endroit où se trouve la variable ne question (stack, dans une structure elle-même sur le tas etc.).
De plus le RAII peut servir a gérer autre chose que de la mémoire: fichier/socket ouvert, mutex etc.
(et Go n'utilise pas de compteur de référence pour son garbage collector, mais du mark and sweep)
[^] # Re: Mais pourquoi diantre pas de RAII ?
Posté par G.bleu (site web personnel) . En réponse à la dépêche De Zig et des zags. Évalué à 8.
Mais là tu parles de garbage collector (dont une des implémentation est le compteur de références qui est mis en oeuvre dans les smartpointers C++)
Le garbage collector est utilisé uniquement pour les allocations dynamiques (si une allocation a lieu sur la stack, on sait que sa durée de vie est liée à l'appel de fonction l'ayant créé, donc pas besoin de check à la runtime pour savoir quand la libérer).
Le RAII est un concept orthogonal au garbage collector: si ton smartpointer est capable de décrémenter le compteur de référence et de faire la libération de mémoire quand celui-ci arrive à zéro, c'est bien que du code a été appelé automatiquement quand la variable contenant le smarpointer a été détruite. Et cela quelque soit l'endroit où se trouve la variable ne question (stack, dans une structure elle-même sur le tas etc.).
De plus le RAII peut servir a gérer autre chose que de la mémoire: fichier/socket ouvert, mutex etc.
(et Go n'utilise pas de compteur de référence pour son garbage collector, mais du mark and sweep)