Je continue d'entendre des gens se plaindre du fait que C++ n'a pas de ramasse-miettes.
Je suis tellement désolé pour eux. Sérieusement.
C++ a RAII, et je me plains toujours de ne pas trouver de RAII (ou un RAII castré) dans les langages avec ramasse-miettes.
Quels avantages la ramasse-miettes pourrait-elle offrir à un développeur C++ expérimenté ?
Un autre outil.
Matt J l'a très bien écrit dans son post (Ramasse-miettes en C++ -- pourquoi ?) : Nous n'avons pas besoin des fonctionnalités de C++ car la plupart d'entre elles pourraient être codées en C, et nous n'avons pas besoin des fonctionnalités de C car la plupart d'entre elles pourraient être codées en Assembleur, etc.. C++ doit évoluer.
En tant que développeur : Je me fiche de la GC. J'ai essayé à la fois la RAII et la GC, et je trouve la RAII largement supérieure. Comme l'a dit Greg Rogers dans son post (Ramasse-miettes en C++ -- pourquoi ?), les fuites de mémoire ne sont pas si terribles (du moins en C++, où elles sont rares si C++ est vraiment utilisé) pour justifier la GC au lieu de la RAII. La GC a une désallocation/finalisation non déterministe et est juste un moyen d'écrire un code qui ne se soucie pas des choix spécifiques de mémoire.
Cette dernière phrase est importante : Il est important d'écrire un code qui "ne se soucie pas". De la même manière en C++ RAII où nous ne nous soucions pas de la libération des ressources car la RAII le fait pour nous, ou pour l'initialisation des objets car le constructeur le fait pour nous, il est parfois important de simplement coder sans se soucier de qui est propriétaire de quelle mémoire, et de quel type de pointeur (partagé, faible, etc.) nous avons besoin pour ce morceau de code. Il semble y avoir un besoin de GC en C++. (même si personnellement je ne parviens pas à le voir)
Un exemple d'utilisation pertinente de la GC en C++
Parfois, dans une application, vous avez des "données flottantes". Imaginez une structure de données en forme d'arbre, mais personne n'est vraiment le "propriétaire" des données (et personne ne se soucie vraiment de quand exactement elles seront détruites). Plusieurs objets peuvent les utiliser, puis les jeter. Vous voulez qu'elles soient libérées lorsque personne ne les utilise plus.
L'approche en C++ consiste à utiliser un pointeur intelligent. Le boost::shared_ptr vient à l'esprit. Ainsi, chaque morceau de données est détenu par son propre pointeur partagé. Cool. Le problème est que lorsque chaque morceau de données peut se référer à un autre morceau de données. Vous ne pouvez pas utiliser de pointeurs partagés car ils utilisent un compteur de référence, qui ne supportera pas les références circulaires (A pointe vers B, et B pointe vers A). Vous devez donc réfléchir beaucoup à l'endroit où utiliser des pointeurs faibles (boost::weak_ptr), et quand utiliser des pointeurs partagés.
Avec une GC, vous utilisez simplement les données structurées en arborescence.
L'inconvénient est que vous ne devez pas vous soucier quand les "données flottantes" seront vraiment détruites. Juste qu'elles le seront.
Conclusion
En fin de compte, si elle est bien faite, et compatible avec les idiomes actuels de C++, la GC serait un Autre Bon Outil pour C++.
C++ est un langage multiparadigme : Ajouter une GC fera peut-être pleurer certains fanboys de C++ à cause de la trahison, mais au final, ce pourrait être une bonne idée, et je suppose que le Comité des Standards C++ ne permettra pas à ce genre de fonctionnalité majeure de briser le langage, donc nous pouvons leur faire confiance pour faire le travail nécessaire pour permettre une GC C++ correcte qui n'interférera pas avec C++ : Comme toujours en C++, si vous n'avez pas besoin d'une fonctionnalité, ne l'utilisez pas et cela ne vous coûtera rien.
