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).
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 :
- 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é.
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 
