Discussion :

[Sandor Dargo]

La norme C++23 supprime la prise en charge du Garbage Collection, par Sandor Dargo, développeur C++

Si nous parcourons la liste des caractéristiques de C++23, nous pouvons tomber sur la notion de garbage collection à deux reprises. Une fois parmi les caractéristiques du langage et une fois parmi les caractéristiques de la bibliothèque. Les deux entrées font référence au même document (P2186R2) : le support du garbage collection (GC en abrégé) est en train d'être retiré du C++. Pour être clair, il n'est pas déprécié, mais complètement supprimé. Comme il s'agit d'une fonctionnalité non implémentée et non supportée, sa suppression est une belle opération de nettoyage du langage. Il ne serait pas non plus surprenant que vous n'ayez jamais entendu parler de GC en C++.

La première surprise que vous réserve cet article est le fait qu'il parle du Garbage Collection et du C++. Lorsque j'ai appris à connaître le C++ par rapport à Java, il y a bien longtemps, l'un des avantages du C++ était la gestion déterministe de la mémoire grâce à l'absence du garbage collection.

Il s'avère qu'en 2008, un support minimal pour le garbage collection et la détection de fuites basée sur l'accessibilité a été ajouté au C++0x. Cet article est basé sur deux articles antérieurs, dont vous trouverez la référence dans l'article cité précédemment. Les garbage collectors standard doivent prendre en compte la sécurité stricte des pointeurs. En fait, il n'existe pas de tels ramasse-miettes dans les principales bibliothèques standard.

N2670 a introduit l'énumération std::pointer_safety avec trois énumérateurs : relaxed, preferred, strict. Lorsque std::get_pointer_safety() est appelée, une implémentation renvoie une valeur indiquant comment elle traite les pointeurs qui ne sont pas dérivés en toute sécurité (voir ci-dessous).

• pointer_safety::relaxed est renvoyé si les pointeurs non dérivés en toute sécurité seront traités de la même manière que les pointeurs dérivés en toute sécurité pendant toute la durée du programme.
• pointer_safety::preferred est renvoyé si les pointeurs non dérivés en toute sécurité seront traités de la même manière que les pointeurs dérivés en toute sécurité, mais en même temps, l'implémentation est autorisée à indiquer qu'il est souhaitable d'éviter de déréférencer ces pointeurs.
• pointer_safety::strict est renvoyé si les pointeurs non dérivés en toute sécurité peuvent être traités différemment des pointeurs dérivés en toute sécurité.

La valeur d'un pointeur est un pointeur dérivé en toute sécurité vers un objet dynamique uniquement s'il est de type pointeur vers objet et s'il l'est :

• la valeur renvoyée par un appel à l'implémentation de ::operator new(std::size_t) de la bibliothèque standard C++ ; le résultat de l'adresse d'un sous-objet d'une valeur résultant du déréférencement d'une valeur de pointeur dérivée en toute sécurité ;
• le résultat d'une arithmétique de pointeurs bien définie utilisant une valeur de pointeur dérivée en toute sécurité ;
• le résultat d'une conversion de pointeur bien défini d'une valeur de pointeur dérivée en toute sécurité ;
• le résultat d'une reinterpret_cast d'une valeur de pointeur dérivée en toute sécurité ;
• le résultat d'une reinterpret_cast d'une représentation entière d'une valeur de pointeur dérivée en toute sécurité ;
• la valeur d'un objet dont la valeur a été copiée à partir d'un objet pointeur traçable, lorsque, au moment de la copie, l'objet source contenait une copie d'une valeur de pointeur dérivée en toute sécurité.

Le standard permet aux implémentations de s'en tirer avec n'importe quelle implémentation de GC, même avec des implémentations no-op, et cela n'a donc pas beaucoup de sens de les inclure dans le standard. Cela ne signifie pas pour autant qu'il n'y a pas eu de garbage collectors réussis pour le C++. Le cas d'utilisation le plus fréquent pour le GC implémenté en C++ est d'avoir des machines virtuelles écrites en C++ pour d'autres langages qui sont garbage collectés. Différentes VM JavaScript sont de ce type, ainsi que Lua.

Mais ces garbage collectors ont aussi leurs propres exigences qui sont influencées bien plus par le langage qu'ils utilisent comme runtime que par le standard C++.

Bien que la norme P2186R2 énumère davantage de problèmes, je pense qu'il est important de mettre l'accent sur deux d'entre eux.

Lorsque vous avez lu ce qui précède à propos de std::pointer_safety, avez-vous compris la différence entre relaxed et preferred ? Si c'est le cas, veuillez nous l'expliquer. Il n'est pas du tout clair sur ce que doivent faire les programmes bien gérés lorsqu'ils reçoivent cette information. Cela ne fait qu'apporter de la confusion sans aucun avantage.

L'autre problème est la définition des pointeurs dérivés en toute sécurité. Pour obtenir un pointeur dérivé en toute sécurité, vous devez utiliser l'opérateur global ::operator new et il n'y a pas d'autres moyens définis par l'implémentation pour obtenir de tels pointeurs. C'est un problème parce que les gens veulent souvent utiliser d'autres news ou éviter complètement leur utilisation pour créer des objets dans des tableaux locaux tout en évitant l'utilisation du heap.

En conséquence, le garbage collection a été supprimé du C++23 dans sa grande majorité, de même que la sécurité des pointeurs. Les noms suivants ont aussi été supprimés de std:: :

• declare_reachable
• undeclare_reachable
• declare_no_pointers
• undeclare_no_pointers
• get_pointer_safety
• pointer_safety

Conclusion

Le Garbage Collection et les fonctionnalités associées ont été retirés du C++23. Si vous êtes surpris d'apprendre que le standard C++ avait un support pour le GC, vous n'êtes pas le seul. Il n'a pas été implémenté, il était confus et plutôt inutile, c'est pourquoi il a été supprimé. Bien qu'il existe des garbage collectors, principalement pour les VM écrites en C++ en tant que runtime pour d'autres langages, ils ne sont pas affectés car ils ne s'appuyaient pas sur le standard, exactement pour les raisons qui ont conduit à sa suppression.

Un peu de simplification de la norme ne fait jamais de mal.

Source : "C++23: Removing garbage collection support" par Sandor Dargo, développeur C++

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi

Les travaux sur la norme C++ 23 sont terminés et cette nouvelle version porte le nom de code "Pandemic Edition", C++ 23 cherche à améliorer la vitesse de compilation et l'hygiène du code

Le comité ISO C++ a proposé une feuille de route pour C++ 23 et finalisé la nouvelle version du langage C++ 20, la norme devrait être publiée dans les mois à venir

[Gugelhupf]

J'avais vu une vidéo de Bjarne parlant de la possibilité d'intégrer un garbage collector au C++ (quelque chose de similaire à Golang), mais je pense que ce projet est complètement tombé à l'eau depuis la monté en popularité de Rust. La force du C ou C++ c'est d'être un langage prédictible, pourquoi enlever cet atout ?

[mintho carmo]

La proposition de GC dans le C++ date de 2011 et n'a jamais été implémenté. Ca n'a jamais réellement intéressé les devs. L'abandon n'a pas grand chose a voir avec Rust. D'autant plus que la proposition de supprimer le GC date d'il y a plusieurs années et n'est donc pas lié à une évolution récente de la popularité de Rust.