IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

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


Sujet :

C++

  1. #1
    Membre à l'essai
    Homme Profil pro
    Inscrit en
    Décembre 2023
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations forums :
    Inscription : Décembre 2023
    Messages : 1
    Points : 15
    Points
    15
    Par défaut La norme C++23 supprime la prise en charge du Garbage Collection, par Sandor Dargo, développeur C++
    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

  2. #2
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    Décembre 2011
    Messages
    1 320
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : Décembre 2011
    Messages : 1 320
    Points : 3 743
    Points
    3 743
    Billets dans le blog
    12
    Par défaut
    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 ?
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ? Contacter Gokan EKINCI

  3. #3
    Membre confirmé

    Profil pro
    Inscrit en
    Décembre 2013
    Messages
    376
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2013
    Messages : 376
    Points : 624
    Points
    624
    Par défaut
    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.

Discussions similaires

  1. Réponses: 1
    Dernier message: 27/07/2023, 19h32
  2. Réponses: 0
    Dernier message: 13/05/2020, 14h17
  3. Réponses: 0
    Dernier message: 30/10/2019, 09h53
  4. Prise en charge des annotations JML par netbeans
    Par touftouf57 dans le forum NetBeans
    Réponses: 0
    Dernier message: 15/09/2011, 17h07
  5. [SQL Serveur] prise en charge de l'arabe
    Par lamiae18 dans le forum MS SQL Server
    Réponses: 4
    Dernier message: 26/03/2004, 13h33

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo